AIはなぜ設計が苦手なのか — 上流工程に必要なコンテキスト一致を考える

2026年10月3日

AIは、システムの運用や障害調査といった下流工程では、実用的な水準で働く。ところが、システム設計のような上流工程になると、途端に物足りなく感じる。この差はどこから来るのか。先に結論を書くと、上流工程は「正解が事実で決まる」領域ではなく「正解が文脈で決まる」領域であり、AIが最も苦手とする暗黙の前提の補完を必要とするからだと考えている。以下、二つの仮説に分けて整理する。

AIは障害調査が得意で設計が苦手 — 体感の正体

まず、この体感が錯覚でないことを確認しておきたい。障害調査の場面では、AIの出力はかなり実務的である。

エラーログやスタックトレースから原因候補を絞り込む
設定ファイルの不整合を指摘する
再現手順を整理し、切り分けの順序を提案する
類似の既知障害を思い出す

これらは、いずれも「与えられた事実の中から整合する説明を選ぶ」作業である。事実は観測でき、正解は一つに収束する。検証もできる。つまり、答え合わせが可能な問題である。

一方、設計では同じようには進まない。要件を渡して「良い設計を考えて」と頼むと、出てくるのは教科書的な一般論か、ありがちなパターンの寄せ集めになりやすい。動くことは動くが、その現場で本当に必要な形にはなっていない。

この差は、能力の差というより問題の種類の差だと考えている。

仮説1 — 上流工程は人間でも高スキルを要する

一つ目の仮説は単純である。人間であっても、上流工程は難しい。だからAIが苦手でも不思議ではない、という説明だ。

これは半分当たっている。設計には、経験に裏打ちされた判断が必要になる。たとえば次のようなものだ。

どの非機能要件を優先し、どれを捨てるか
どこで抽象化を止めるか（作りすぎない線引き）
数年後に伸びる方向を読み、今の構造にどう余裕を持たせるか
組織の運用体制と噛み合わせ、無理なく回る形に落とす

これらは正解が一意でない。むしろ、複数の正解の中から、その状況に合うものを選ぶ作業である。人間でも、失敗を重ねて身につける領域だ。要件を引き出す側の技術については、提案依頼書（RFP）の書き方でも扱っているが、あの文書づくりそのものが「暗黙の前提をどこまで外に出すか」という作業になっている。

ただし、この仮説だけでは説明が足りない。AIは、人間が何十年もかけて蓄積した設計知識を大量に読んでいる。パターンもアンチパターンも知っている。それでも設計が弱いのはなぜか。ここで二つ目の仮説が必要になる。

仮説2 — 上流工程はコンテキスト一致を強く要求する

二つ目の仮説は、上流工程ほど「書き手と読み手のコンテキスト（文脈）の一致」を強く要求するというものである。

設計とは、突き詰めれば「制約の塊の中から、妥当な一点を選ぶ」作業である。そして制約の多くは、明文化されていない。

なぜこのシステムが生まれたのか（経緯）
誰が使い、誰が運用するのか
過去に何を試して、何が嫌になったのか
今後どこまで拡張する予定があるのか
予算・人員・納期はどうなっているのか
組織内で、触れてはいけない領域はどこか

障害調査では、こうした背景はほとんど要らない。ログと設定がすべてを語る。ところが設計では、これら暗黙の前提が答えの大半を決める。

AIに設計を頼むとき、私が渡すのはたいてい「要件」と「現状の構成」だけである。経緯も、運用の肌感覚も、組織上の制約も渡していない。渡していないものを補完することは、原理的にできない。結果として、コンテキストが空いた状態で一般論が出てくる。

つまり、AIが設計を苦手に見えるのは、AIの能力の問題である以前に、必要なコンテキストが入力されていない問題である可能性が高い。

障害調査と設計の決定的な違い — 正解は事実で決まるか文脈で決まるか

ここで両者を対比して整理しておく。障害調査は、次の性質を持つ。

観測可能な事実（ログ・メトリクス・設定）が存在する
正解が一つに収束する（再現すれば確定する）
検証が即座にできる（直せば治る）
前提の多くが、対象の中に閉じている

この四つが揃うと、AIの強みが最大化される。大量の知識から候補を出し、事実で絞り込み、検証で確定する。この流れは、AIが最も得意とする推論の形である。さらに障害調査は繰り返しが効く。同じ型の問題が何度も起きるので、一度学べば次に活きる。学習の蓄積が成果に直結する。

対して設計は、性質がほぼ正反対である。

観測すべき事実が、そもそも外にない（人の頭の中にある）
正解が複数あり、状況で変わる
検証が遅い（数年後に効いてくる）
前提の多くが、対象の外側（組織・歴史・予算）にある

この条件では、AIは力を出しにくい。入力されていない情報を、いくら推論しても出てこない。もっともらしい一般論を作ることはできても、その現場の最適解にはならない。

ここで重要なのは、これはAI固有の欠陥ではないという点である。人間の新しい担当者も、着任直後は同じ壁にぶつかる。経緯を知らず、運用の肌感覚もなく、組織内の地雷も知らない。だから最初は一般論しか言えない。そして、聞き取りと対話を通じてコンテキストを埋めていき、数か月かけて設計力が上がっていく。

上流工程の難しさの正体は、思考力の差ではなく、コンテキストの獲得コストの高さにある。AIは、この獲得コストを自力では払えない。ここが決定的な違いである。

具体例で考える — 同じ設計でもコンテキストで答えが変わる

たとえば「問い合わせ対応を自動化したい」という依頼を考える。要件だけを渡すと、AIは一般的なチャットボット構成を返してくる。FAQ を用意し、意図分類を挟み、回答できない場合は人にエスカレーションする。教科書どおりで、間違ってはいない。

しかし、この現場の実情はこうかもしれない。

問い合わせの七割は、実は既存の社内システムの操作ミスが原因
操作ミスの背景には、画面の分かりにくさがある
根本原因を放置して自動化すると、誤案内が増える
過去に自動応答を導入して失敗した経緯があり、現場は警戒している

この情報を渡すと、答えはまるで変わる。自動化すべきは問い合わせ対応ではなく、画面の改善かもしれない。あるいは、自動化の前に運用の立て直しが先かもしれない。

同じ「設計」という言葉でも、渡されるコンテキストの量で答えの質が決まる。 これはAIに限った話ではない。人間のコンサルタントでも、ヒアリングをせずに提案書を書けば同じ結果になる。

インフラの設計判断も、同じ構造にある。たとえば脱・高コストSAN！ProxmoxとInfiniBandで実現する次世代HCIのような構成は、技術的に成立するかどうかだけでなく、予算・既存資産・運用要員のスキルという制約の下で選ばれている。一般論として「HCIが良い」と言うことはできても、その組織にとって最適かどうかは、制約を知らなければ判断できない。

設計コンテキストの供給不足はなぜ起きるのか

では、なぜ設計の場面ではコンテキストが足りないのか。理由は三つある。

一つ目は、本人も言語化していないことだ。設計に必要な前提は、依頼する側の頭の中に、暗黙の常識としてある。常識は、わざわざ説明されない。説明されない情報は、入力に乗らない。

二つ目は、渡す側が「渡したつもり」になることだ。要件定義書や現状構成図を渡せば、情報は伝わった気になる。しかし設計を決めるのは、むしろそこに書かれていない部分である。

三つ目は、コンテキストは会話の中でしか出てこないことだ。聞かれれば答えるが、聞かれなければ出てこない情報というものがある。設計の前提は、その典型である。

障害調査では、この三つが問題にならない。対象の中に答えがあるからだ。設計では、すべてが問題になる。

設計を支援するために何を外部化すべきか

この整理から、対策の方向は見えてくる。設計に必要なコンテキストを、いかに外部化して蓄積し、参照できるようにするかである。

考えられる要素は、次のようなものだ。

設計判断の記録（何を、なぜそう決めたか。採用しなかった案とその理由）
用語と概念の定義（その組織でだけ通じる言葉の意味）
制約の一覧（予算・納期・人員・運用体制・触れない領域）
過去の失敗と、そこから得た線引き
関係者の優先順位

これらが溜まっていれば、AIは設計の場面でも一般論を脱せる可能性がある。逆に言えば、これらが無いままAIに設計を頼むのは、無い情報を無いまま答えさせているに等しい。

私自身の運用でも、障害対応の記録は比較的自然に残る。原因と対策が明確で、書く動機があるからだ。ところが設計の判断理由は残りにくい。正解が無く、書いても「後から見れば間違っていた」可能性があるためだ。ここを残す仕組みを作れるかどうかが、分かれ目になる。

AIを使いこなすことは、社員を活かすことに似ている

設計に必要なコンテキストを外部化するという話は、そのまま人材育成の話に重なる。ここまで考えてきて、AIを使いこなすことと、社員を活かすことは、構造としてよく似ていると感じるようになった。

新しい社員が戦力になるまでには、時間がかかる。技術的なスキルは教えられるが、それだけでは動けない。過去に何があり、なぜ今の形になっているのか。どこで失敗し、そこから何を学んだのか。経営者がどのような判断をし、その理由は何だったのか。こうした文脈を知って初めて、その組織に合った仕事ができる。

これは、先に見たAIの設計力の話と、まったく同じ構造である。スキルだけを渡しても、コンテキストが無ければ一般論しか出てこない。人間でもAIでも、答えの質を決めるのは、暗黙の前提をどれだけ共有できているかである。

したがって、社員教育をスキルに偏重させるのは、コンテキストを渡さずにAIへ設計を頼むのと同じ失敗を招く。過去のナレッジ、判断の記録、その理由。これらを伝えることが、結果として戦力を引き上げる。

AIに暗黙知を与える仕組みとして注目されるRAG（検索拡張生成、Retrieval-Augmented Generation）も、やっていることは同じである。組織の中に散在する文書や記録を、必要なときに参照できる形にする。これは技術の話であると同時に、組織が自分の知識をどう扱うかという話でもある。

松下幸之助は、経営の根底に「人間理解」を置いたとされる。AIという存在を理解しようとすると、思いのほか人間そのものの理解が進む。AIはこれが苦手、という観察が、人間でも同じではないかという結論に至り、では人にはどう伝えればよいのか、という問いに変わる。道具を理解する作業が、人の理解に接続していく。

AIを使いこなすことと、社員を活かすことは、似ている。どちらも、相手の中にある文脈をどれだけ引き出し、共有できるかで成果が決まる。

この整理でも説明できない部分

正直に書くと、この整理でも割り切れない部分は残る。

コンテキストを十分に渡しても、AIの設計が人間の熟練者を超えるとは限らない。判断の重みづけ、複数の制約が衝突したときの優先順位、説明できないが違和感があるという直感。これらは、まだ言語化しきれていない。

また、AIは過去の一般解に引っ張られやすい。前例のない構造を選ぶ場面では、無難な側に寄る傾向があるように感じている。これは設計というより、新しいものを選ぶ意思決定の難しさであり、別の論点である。

だから本稿の結論は「コンテキストを渡せばAIが設計できる」ではない。「コンテキストが無い状態では、AIは設計できない」である。ここを混同すると、期待外れの結論に飛びつくことになる。

AI時代の上流工程 — 人間とAIの役割分担

以上を踏まえると、役割分担の形も見えてくる。

人間は、暗黙のコンテキストを持っている側である。したがって、コンテキストを引き出し、言語化し、判断の責任を負う役割を担う。

AIは、言語化されたコンテキストを前提に、選択肢を広く出し、比較し、抜け漏れを指摘する役割を担う。設計の答えを独力で出すのではなく、人間が答えに至る速度を上げるために使う。

この分担なら、AIの強みはそのまま活きる。事実に基づく整理、選択肢の網羅、過去事例との突き合わせは、まさに得意分野である。

逆に、コンテキストを渡さずに「良い設計を」と丸投げする使い方は、AIの弱点を最も突く使い方になる。能力の限界ではなく、使い方の問題である。AIを業務に持ち込む際の障壁については、日本のAI導入率はなぜ低いのかで扱った文化的な要因も絡んでくる。ツールの問題と、渡し方の問題は、切り分けて考える必要がある。