AI の回答が「自分の現場にとって」正しいかをどうすり合わせるのか

はじめに

ここ数年で AI は驚くほど賢くなり、技術的な質問にもほとんどの場合で的確な答えを返してくれるようになりました。 コードのレビュー、エラーの原因究明、設定の書き方まで、すべてを解決できるわけではありませんが、たいていは AI に質問すれば解決の糸口が見えます。

一方、AI が役に立たないと感じられるケースは、大きく二つに分けられます。一つは、事実として間違っている回答を返す場合です。これは「AI の回答には間違いを含むから注意して、ちゃんと検証しよう」という形ですでに多くの記事が扱っています。本記事では深入りしません。

もう一つは、事実としては正しいのに、自分の現場では使えない回答を返すケースです。

特に指示がない場合、AI は学習データの平均、いわば教科書的なベストプラクティスを回答として返します。 この答えは一般論として完璧に正しいのですが、現場固有の制約や、そこで意図的に選んでいる工夫を無視しているために、まるで使えないと受け取り手が感じてしまうことがあります。

本記事のテーマは、この「一般論」を 自分たち主体の回答へすり合わせ、現場で使える答えを聞き出すにはどうするか、です。 題材は IT 技術ですが、考え方は他分野にも応用できると思います。

なぜ AI は「正しいのに使えない」答えを返すのか

理由はシンプルで、AI はあなたの現場の制約を知らないからです。固有の事情――例えば、会社やプロジェクトの方針、サービスドメインの顧客の性質、過去の障害から得た教訓、性能要件の優先順位や社内事情など――は AI の学習データには含まれていません。これらの情報なしに AI に質問しても、AI はその内容を手がかりに、世間一般の最頻値を返しているにすぎません。 

具体例を挙げます。

新しく AWS でサーバーとデータベースを構築したい、とだけ伝えると、いずれも VPC・EC2・RDS を使った“とりあえず動く”最小構成を手早く提示してきました(記事執筆時現在、Gemini, Claude で確認)。どちらの回答も、こちらが本当は何を優先したいのか(コストを切り詰めたいのか、可用性を確保したいのかなど)を知らないまま出てきたものです。そこで「コストを最優先したい」という前提を与えると、単一インスタンス構成や Amazon Lightsail のような選択肢へと回答が変わっていきます。 

Docker を使わないオートスケーリング構成で WordPress を動かすとき、「新規インスタンスに最新の状態を共有したい」とだけ相談すると、AI は EFS での共有や、コードをイメージに焼き込む構成(baked AMI)などを提示してきます。いずれも教科書的には妥当な答えです。
ただし、ここには WordPress 固有の事情があります。コードと状態を分離できるモダンなアプリと違い、WordPress はプラグインやテーマの導入・更新、メディアのアップロードといった管理操作が、実行環境のファイルそのものを書き換えます。つまり「動いている本体が書き換わる」前提のシステムで、各インスタンスを使い捨てにするイミュータブルな構成とは本来相性がよくありません。
そのため現場では「正本となる Master インスタンスを置き、スケーリング側はそこから定期的に同期する」という構成を採ったことがあります。Master は単一障害点になりますが、管理機能やバッチの起点をそこに集約でき、同期が一時的に失敗してもスケーリング側のアプリは動き続けます。こうした「何を諦め、何を取るか」の判断は、現場の事情を前提として渡さない限り、AI の口からは出てきません。 

いずれの例でも、AI の回答は教科書的には 100 点で、間違ってはいません。しかし、実際に現場で採用すると、想定していた結果が得られないことがあります（コストが想定よりかさむ、性能が出ない、運用が回らない、など）。これらは、分かりやすいエラーではなく、多くが非機能要件に関わる話であるため、気づかずに採用してしまい、後から問題に気づく、という危険があります。 

自分たち主体の回答を聞き出す

対策の方向ははっきりしています。現場の制約をこちらから前提として渡し、生成のさせ方そのものを変えることです。

漠然と「最適解を出して」と丸投げすると、一般論しか返ってきません。そうではなく、土俵を自分の側に引き寄せます。

• 現場の情報を前提として渡す：バージョン、構成、性能要件、そして「なぜ今この形にしているのか」という制約や意図まで言語化・数値化して伝える。AI が一般論に逃げる余地を減らします。
• 自分のアイデアを添削・評価させる：「コスト都合で冗長化はあえて捨てている。この構成をどう評価する？」という形にすると、制約は自分が握ったまま、AI に粗探し役を担わせられます。
• 自分の案と比較する形で対案を出させる：「今は EBS にソースを置く方針。これと EFS 案を IO 性能の観点で比較して」のように、自分の案を土俵に置いて議論を引き寄せます。

要は「主導権は自分が握り、AI は壁打ち相手にする」という構図です。ゼロから答えを生成させるのではなく、自分の判断を補強・検証させる道具として使う。この発想の転換だけで、実用度は格段に上がります。

使い道で、かける手間を変える

すり合わせにかける労力は、その回答をどこで使うかで調整します。ちょっとしたツールを作るだけなら、多少ズレた回答が出力されても、それを実際に動かせばエラーとなるのでそこで気づき、適切な修正が可能です。一方、会社の資料や公開記事のソースにするなら、ズレがそのまま世に出てしまうため手を抜けません。「どこで手を抜き、どこで踏ん張るか」の線引きこそが、AI を使う技術だと思います。

なお本記事の主眼ではありませんが、「自分たち主体の回答」を引き出せても、その中身に事実誤認が混じる可能性は残ります。コードなら動かす、仕様なら公式ドキュメントなど一次情報に当たる、といった最低限の突き合わせは別途行いましょう。

見落とされがちな「カットオフ」という前提

ここまで「AI はあなたの現場を知らない」と述べてきましたが、AI が知らないものはもう一つあります。それが学習データの区切り（カットオフ）以降に起きた、世界の側の変化です。これは地味に見落とされがちです。AI は無知なのではなく、ある時点で時間が止まった知識を、さも現在のことのように自信たっぷりに回答します。

実際に遭遇した例を挙げます。PHP の Docker イメージで拡張を整える場面で、AI が「本番なら効かせたいので docker-php-ext-install opcache で OPcache を追加するのがおすすめ」と提案してきました。これは PHP 8.4 以前なら正しいアドバイスです。

ところが PHP 8.5 では事情が変わっています。OPcache は常に PHP バイナリに組み込まれ常時ロードされるようになり、拡張として別途インストールする対象が存在しなくなりました。

これを知らずに docker-php-ext-install opcache を実行すると、コンパイル対象がないためビルドが失敗します。AI は 8.5 のこの変更を学習しておらず、古い常識のまま答えていたわけです。

ここでも効くのは、これまでと同じ「前提を渡す」姿勢です。「PHP 8.5 だと OPcache はデフォルトで入っていて後から入れられないのでは？」と具体的に聞き返したところ、AI はウェブ検索でこちらの認識が正しいことを確認し、回答を訂正しました。現場の最新状況も、現場の制約と同じく、こちらから前提として渡してやる必要があるのです。

新しめの技術を扱うときは「学習タイミングの都合で古い前提のまま答えていないか？」と一度疑いましょう。ウェブ検索を有効にできる環境なら、AI 自身が最新情報を取りに行けるため、この種のズレはかなり緩和されます。あわせて現在の日付を伝えておくと、AI が「自分の知識は古いかもしれない」と意識し、検索や確認に動きやすくなります。 

まとめ

今日の AI はたいていは正しい答えを返します。 ただし、この正しさはあなたにとっての正しさとは限りません。 あなたにとって正しく、役に立つ回答を引き出すには、以下のような聞き出し方と注意点がある、という事を説明しました。 

• 丸投げしない：AI は現場の制約を知らない。ゼロから生成させると一般論しか返らない。
• 主導権を自分が握る：現場の情報を前提として渡し、自分の案を添削させ、対案と比較させる。AI は答えを出す相手ではなく、判断を補強・検証させる壁打ち相手。
• いつの話かも前提として渡す： AI の知識はカットオフで止まっている。新しい技術ほど、現場の最新状況をこちらから伝える必要がある。
• 最後は自分が判断する：すり合わせとは、現場と AI を突き合わせ、制約自体の妥当性まで含めて自分で決めること。

賢くなった AI を頼れる相棒にするか、見えない地雷にするか。それを分けるのは、当たり障りのない一般論を無批判に飲み込まず、自分の文脈に照らして回答の評価を行い、自身の責任で利用することだと思います。