技術選定の不確実性に向き合うための アーキテクト思考

技術選定の不確実性に向き合うための アーキテクト思考 • Feb. 26, 2026 • Takeshi Yonekubo • 技術選定を突き詰める Online Conference 2026

技術選定とは？

「技術」 ・ソフトウェア開発で利用するミドルウェア、ライブラリ、ツ ール ・アーキテクチャやコンポーネントを設計する 技 3

「選定」 選ぶ 複数の候補から、目的に合うものを選ぶ 定める 絞り込んで、意思決定する 4

技術選定の難しさ ・要件を正しく捉えることが難しく、時間の経過につれて移り 変わる ・技術的な選択肢も多い上、変化のスピードが速い ・複雑で高度な、プレッシャーのかかる意思決定を求められる 5

技術選定の「技術」が 暗黙知 となってい る

本日のゴール ジュニア これから技術選定を行ううえで必要な原理原則、基本を知る ベテラン 技術選定という営みを見つめ直し、暗黙知を形式知化する 7

自己紹介 米久保 剛 ITアーキテクト 『アーキテクトの教科書』（翔泳社） 8

1. 技術選定の本質

なぜ技術選定をするのか？

そこに、技術で解決したい 課題 があるか ら。

例: git 現在、「gitを使うかどうか」が技術選定対象となることはほぼ ない 12

Subversion (SVN) かつてはSubversionを当たり前のように使っていた時代があっ た。 ・中央集権型 ・ブランチのマージが苦痛（解決すべき課題） 13

SVN → git ・ツールの充実 ・GitHubエコシステム ・ブランチモデルなどノウハウの普及 →「gitを使わない理由」を探す方が難しく、選定プロセスを発 動する必要がなくなった 14

周辺の技術選定 gitを使ううえで、技術選定の発動候補はある： ・ホスティングサービス（GitHub / GitLab） ・プラン（Free / Team / Enterprise） ・リポジトリ構成（モノレポ / マルチレポ） ・クライアント（CLI / SourceTree / GitKraken / IDE統合） → 個別の状況に応じて、技術選定の要否は異なる 15

git → ？ gitが「当たり前」でなくなり、選定対象となる日も来るかもし れない。 例）git worktreeを活用した、AIエージェントによる並行開発 → 既存の技術の枠組み内で課題解決をしているが、「そもそも AI開発を前提としたバージョン管理ツール」が出てくる可能性 16

小まとめ 何のために技術選定をするのか／しない のかを明らかにする。

2. 見えない敵：認知バイアス

選定を行うのは人間 （バイブコーディングを除く）

人間の認知の仕組み システム1（速い思考） 直観的・無意識。パターン認識で即座に判断 システム2（遅い思考） 論理的・意識的。複雑な分析や計算に使う 技術選定はシステム2で行うべきだが、システム2は怠惰なので、システム1に任 せがち → エラー発生リスク ※参考文献: ダニエル・カーネマン『ファスト＆スロー』 20

直観 ・熟練した消防士は、建物に入った瞬間「何かおかしい」と感 じて撤退を命じ、直後に床が崩落した ・経験に裏打ちされたパターン認識（システム1）が危険を察 知 ・熟練したベテランアーキテクトにも、同様の直観がはたらく ・ただし個人の暗黙知にしておくのはもったいないし、スケー ルしない → 形式知化が必要 21

認知バイアス ・人間の認知や判断には系統的な歪み（バイアス）がある ・経験則（ヒューリスティック）は普段は便利だが、技術選定 のような複雑な判断では落とし穴になる ・認知バイアスを知っておくことで、回避しやすくなる 22

認知バイアスの例 バイアス名 説明 確証バイアス 自分の仮説を支持する情報ばかり集めてしまう 権威バイアス 有名企業や著名人が使っているという理由だけで選んで しまう みんなが使っているから正しいと判断してしまう バンドワゴン効果 ハロー効果 現状維持バイアス 一つの優れた特徴があると、他の面も優れていると判断 してしまう 変化を避け、慣れた技術を選び続けてしまう サンクコスト効果 すでに投資した時間や労力を惜しんで誤った選択を続け てしまう 利用可能性ヒューリスティック 最近見聞きした情報や印象的な事例に影響されやすい 23

確証バイアス 自分の仮説を支持する情報ばかり集めてしまう 「マイクロサービス化すべきだと思う。A社やB社で成功して いるし、書籍も多い」 → 失敗事例や、モノリスの方が適している状況の情報を探して いない 24

バンドワゴン効果 みんなが使っているから正しいと判断してしまう 「最近の開発現場ってみんなReact使ってるよね。うちもフロ ントエンドはReactにしよう」 → 自社のプロジェクト特性や、チームのスキルセット、Vue.js やSvelteなど他の選択肢を冷静に評価していない 25

利用可能性ヒューリスティック 最近見聞きした情報や印象的な事例に影響されやすい 「先週のカンファレンスでRustの事例を聞いた。うちもRust で書き直したらパフォーマンス上がるんじゃない？」 → 最近見聞きした印象的な情報に影響され、学習コストや適用 範囲を冷静に評価していない 26

バイアスを回避するには ・自分の思考のクセを知る ・人の振り見て我が振り直せ ・メタ思考（幽体離脱） 27

メタ思考：思考実験によるテスト テスト名 問いかけ ダブルスタンダード・ テスト 部外者テスト 個人や集団を、他とは違う基準で判断していないか？ 同調テスト もし他人が意見を変えても、私は同じ意見を持ち続ける だろうか？ この証拠が反対意見を支持しているとしたら、どの程度 信用できるか？ もし現在の状況が今と違っていたら、積極的にそれを取 り戻そうとするか？ 選択的懐疑主義テスト 現状維持バイアステス ト 赤の他人なら、この状況をどのように考えるだろうか？ ※参考文献: ジュリア・ガレフ『マッピング思考』 28

部外者テストの事例：インテルCEO 1980年代半ば、インテルはメモリ事業で日本企業との競争に苦 しんでいた。 「もし私たちが会社を追い出されたとしたら、新しいCEOは何 をするだろうか？」 — グローブ 「半導体メモリ事業から撤退するだろうな」 — ムーア 「私たちの手で、半導体メモリ事業を撤退すべきじゃないか？」 — グローブ → インテルはメモリ事業から撤退し、マイクロプロセッサに集 中。大成功へ。 29

小まとめ 認知バイアスを自覚し、メタ思考を 活用して回避する。

3. 見えない死角：未知の既知

ラムズフェルドの4象限 × 技術選定 知っている (Known) 知らない (Unknown) 知っている (Known) 知らない (Unknown) 既知の既知 既知の未知 通常のトレードオフ分析で対処で きる 調査やPoCで解消できる 未知の既知 未知の未知 知見はあるのに視野に入っていな い 柔軟性や、決定を遅らせることで 対応 32

既知の既知 (Known Knowns) 通常のトレードオフ分析で対処できる ・何を知っているかがわかっている状態 ・技術選定において最も扱いやすい領域 ・明確な基準で比較・評価が可能 ・例：料金体系、ライセンス形態、カタログベースでの機能有無 33

既知の未知 (Known Unknowns) 調査やPoCで解消できる ・何を知らないかがわかっている状態 ・不明点は明確だが、答えがまだわかっていない ・体系的なアプローチで解消可能 ・例：本番相当負荷での性能、詳細要件に対する適合性調査 34

未知の既知 (Unknown Knowns) 個人や組織内に知見はあるのに選定者の視野に入っていない ・実は知っているのに、気づいていない状態 ・組織内で知識が共有されていない ・認知バイアスによる盲点 ・例：運用チームだけが知っている本番の痛み、過去に似た技術 を見送った理由、隣のチームの導入経験 35

未知の未知 (Unknown Unknowns) 柔軟性や、決定を遅らせることで対応 ・何を知らないかすらわかっていない状態 ・技術選定において最もリスクが高い領域 ・予測不可能な問題や機会 ・例：ベンダーの突然の方針転換、規制変更、想定外のユース ケースの出現 36

「未知の既知」に手を打つ ・未知の未知に備えることはなかなか難しい ・未知の既知には手を打つことができる 37

未知の既知の具体例 誰が知っているか 選定者から見えていないこと 気づかないとどうなるか 運用チーム 類似技術で過去に苦労した監視・障害 運用コストが想定を大幅に 対応の実態 超える セキュリティ・法務 データの機密性に関する法的要件、監査 セキュリティレビューで差 ログの要件 し戻し 過去の自分たち 数年前に同種の技術を検討・見送った 同じ落とし穴を踏む 理由 隣のチーム 同じ技術をすでに導入済みで、ハマり 既知の問題を一から踏み直 どころを経験済み す 38

「見える」は「気づく」 何度も言うが「見える」は「気づく」だ — 江口夏実 『出禁のモグラ』第2巻 39

「気づく」ための仕組み化 1. ADR (Architecture Decision Record) 過去に行った判断理由を検索可能にする 2. ステークホルダーの巻き込み 選定プロセスに必要なステークホルダーを巻き込む 3. 選定のふりかえり 「あの選定は正しかったのか」答え合わせを行う 40

小まとめ 見えていないことに気づく仕組みづくり が重要。

4. トレードオフ分析の要諦

題材：最近あった具体例 ・「開発チームに Claude Code を導入したい」 ・提案されたプランについて意思決定（承認）が難しかった 43

意思決定が難しかった理由 ・比較評価軸の設定基準や妥当性があいまい ・トレードオフ分析と結論との因果が弱い ・思い込みや認知バイアスが払拭できていない 44

どうしたか AIにディープリサーチさせて、出力レポートを一緒に眺めなが ら技術選定のポイントを共有した上で、プランを選定した。 評価軸の設定 → AIによる調査 → 一緒にレビュー → 選定 45

※レポート全文は補足資料として公開 https://claude.ai/public/artifacts/cec2097f-b5ee-47cf-99fb-9784aa0ee321 47

• https://claude.ai/public/artifacts/cec2097f-b5ee-47cf-99fb-9784aa0ee321

レポート（サンプル）— 評価軸一覧 # 評価軸 重要度 1 管理者アカウント・2FA 最重要 2 データ学習除外 最重要 3 Claude Code・Claudeアプリ対応 重要 4 開発者の日常利用に十分な使用量 重要 5 定額・追加料金・上限設定 重要 6 ログ・認証 重要 7 SSO/SAML連携 中 8 データ・リージョン 中〜高 ※レポート全文は補足資料として公開 https://claude.ai/public/artifacts/cec2097f-b5ee-47cf-99fb-9784aa0ee321 46

• https://claude.ai/public/artifacts/cec2097f-b5ee-47cf-99fb-9784aa0ee321

レポート（サンプル）— 比較表の一部 評価項目 Pro/Max Team Enterprise 管理者アカウント データ学習除外 △（手動オプトアウ （デフォルト除 （デフォルト除 ト） 外） 外） SSO (SAML/OIDC) 監査ログ 基本的 包括的 ※レポート全文は補足資料として公開 https://claude.ai/public/artifacts/cec2097f-b5ee-47cf-99fb-9784aa0ee321 47

• https://claude.ai/public/artifacts/cec2097f-b5ee-47cf-99fb-9784aa0ee321

評価軸の設定 ・比較評価する観点や項目の洗い出し: 一般的な品質特性リス トから導出、AIと壁打ち等 ・重要なのは、優先度付けを先に行うこと ・とくに、絶対に譲れない最重要な項目は何か？ 48

具体例：今回の場合 最重要 大企業で、（評価目的でなく）本番利用する上でのセキュリテ ィ要件を満たすこと 重要 その上で、利用したい機能を十分に利用できること（機能適合 性・可用性・経済効率性） 49

なぜ評価軸を「先に」定めるのか 認知バイアスの回避 確証バイアスによって、結論ありきの評価軸設定をしてしまう リスク 総合点方式の罠 点数は参考にはなっても、それだけで意思決定するのは危険 合意形成プロセス 優先する評価軸を検討し、ステークホルダー間で合意形成を行 う行為そのものが技術選定の根幹 50

小まとめ 評価軸を選ぶことが、技術選定という 意思決定プロセスの要。

5. AI時代の技術選定

AIで変わったこと ・ ・ ・ ディープリサーチによる高速・網羅的な調査 AIエージェントによる並列でのPoC・実装検証 「平均への回帰」リスク 53

技術選定の「いつ」が変わる Last Responsible Moment（最終責任時点） 重要な意思決定は、それ以上遅らせると悪影響が出る直前まで 先延ばしにする ・不確実性が高いものは判断を遅らせる合理性がある ・AIで調査や検証が高速化し、LRMの後ろ倒しが可能に 54

不確実性を管理する ・意図的に「遅らせる」ことと「考えることを先延ばしする」 ことは違う ・不確実さの性質によって、管理の打ち手が変わる 55

ラムズフェルドの4象限 × 不確実さの管理 象限 不確実さの性質 管理戦略 AIの活用 既知の既知 度合いがわかっている 選定時期を計画する 低い 既知の未知 度合いがわからない 調査・PoCで輪郭を掴む 高い 未知の既知 存在に気づいていない 顕在化させる 高い 未知の未知 管理不能 柔軟性で備える 限定的 56

既知の既知：選定時期を計画する ・不確実さの度合いがすでにわかっている ・例：半年後のメジャーバージョンアップで破壊的変更がある ・変動要因が少ないものは早期に決定し、変動が見込まれるも のはその時を待つ ・遅らせるにしても「いつ決めるか」を今決められる 57

既知の未知：調査で不確実さの輪郭を掴む ・不確実さがあることはわかっているが、度合いがわからない ・例：公開情報が少ない、経験者が少ない、ベンチマークがな い ・AIによる調査・PoCで「何がどのくらいわからないか」を測 定可能にする ・LRMが最も効く象限。AIで調査コストが下がり、遅延の選択 肢が広がった 58

未知の既知：問いを見つける ・知見は存在しているが、選定者の視野に入っていない ・AIが効くのは「答えを探す」だけではない。「問いを見つける」にも使える ・外の知見：ディープリサーチによる一般的な事例調査 ・中の知見：エンタープライズサーチで社内の類似情報を横断検索 ・ADRを書いて蓄積しておくと、AIで検索可能な組織知になる → ADRの価値がAI時代にさらに高まる 59

未知の未知：柔軟性で備える ・不確実性の管理が不能な領域 ・唯一できることは、決定の可逆性を高めておくこと 例：特定技術へのロックインを避ける抽象層 60

AI固有のバイアス AIの徹底活用により不確実性の管理可能性を高めることができ るが、AIが持っている「バイアス」には注意が必要 ・ハルシネーション — 間違える前提で、チェックと訂正のプ ロセスを設計すべき ・ユーザーへの忖度 — 期待に沿った回答を出しがち。人間の 確証バイアスとの相乗効果も ・平均への回帰 — 学習したデータの平均へと収束しやすい。凡 庸な技術選定をしてしまうリスク 61

平均への回帰を防ぐ 「流されるな、選べ」 アーキテクト、テックリードとして「エッジの効いた」技術選 定をできるように、審美眼を磨き続けなくてはならない

小まとめ AIの活用で不確実性は管理しやすくなるが、 最後に「選び」「定める」のは人間の審美眼

まとめ

Key Takeaways 1. 技術選定の本質 — 何のために技術選定をするのか／しない のかを明らかにする 2. 認知バイアスへの対処 — 認知バイアスを自覚し、メタ思考 を活用して回避する 3. 未知の既知の可視化 — 見えていないことに気づく仕組みづ くりが重要 4. トレードオフ分析 — 評価軸を選ぶことが、意思決定プロセ スの要 5. AI時代の技術選定 — 最後に「定める」のは人間の審美眼 65

不確実性は避けられない。 しかし、見えないものを見えるようにし、 正しいプロセスで意思決定すれば、 逆境は乗り越えられる。

ありがとうございました

参考文献一覧 文献 著者 備考 『ファスト＆スロー――あなたの意思はどのように決 ダニエル・カーネマ システム1/2、消防士のエピソ まるか？』（早川書房） ン ード 『マッピング思考――人には見えていないことが見え ジュリア・ガレフ てくる「メタ論理トレーニング」』（東洋経済新報社 ） メタ思考テストの出典 『出禁のモグラ』第2巻（講談社〈モーニングKC〉） 江口夏実 「見える」は「気づく」の引用 『アーキテクトの教科書――価値を生むソフトウェア 米久保 剛 のアーキテクチャ構築』（翔泳社） 発表者の著書 68