はじめに
生成AIの記事はもう飽きるほどあります。それでも書こうと思ったのは、社内向けに利用ガイドを書いたときに気づいたことがあったからです。
研修を受けた人に話を聞くと、みんな一様に「知っている」と言うのです。ChatGPTも触ったことがある、Copilotも入っている、と。ところが「業務で何に使っていますか」と聞くと、途端に歯切れが悪くなる。せいぜい調べ物に使う程度で、手順書を書かせたことも、設定をレビューさせたこともないという人が大半でした。
知識と実践の間に、思ったより深い溝があるようです。
私自身、20年近くインフラ構築をやってきて、生成AIを本格的に業務で使い始めたのは比較的最近です。ここでは、その過程で戸惑ったことと、それに対してどう対応したかを書いていきます。慣れている人からすれば当たり前の話も含まれますが、お付き合いください。
なお、この記事の情報は2026年9月時点のものです。後述しますが、この分野は半年で景色が変わります。モデル名や機能については各自で最新をご確認ください。
その前に ― 読む前に30分だけ手を動かしてほしい
順番が前後しますが、先にこれを置いておきます。
この手の記事の最大の問題は、読んで満足して終わることです。私が社内向けに書いたガイドも、初稿は「よくできた教科書」でしたが、レビューで「読むだけで行動が変わらない」と指摘されました。もっともな話です。
そこで、本編に入る前に30分だけ使ってほしい手順を書いておきます。
- 直近で「面倒だな」と思った作業を1つ選ぶ（手順書の下書き、ログの確認、設定のレビュー、知らない用語の調査、なんでも構いません）
- 下のテンプレに当てはめて投げる
- 出てきたものを手直しして、実際に使う
【環境・前提】（OS、バージョン、構成など、AIが知らない情報）
【やりたいこと】（達成したいゴール）
【欲しいもの】（手順 / コード / 比較表 など、出力の形）
前提が足りなければ質問してください。
返ってきたものは、そのまま使えそうに見えるかもしれません。それでも一度は自分の目で確認して、直すべき箇所を探してください。成果物として受け取るのではなく、叩き台として受け取る。この一往復を体験しておくと、以降の話が自分ごとになります。
ちなみに1回だけだと「たまたまうまくいった」で終わりがちなので、翌日にもう1回、その次にもう1回やってみることをお勧めします。3回やると手が勝手に伸びるようになります。私の場合はそうでした。
＊機密情報の扱いについては後述します。最初の一歩を踏み出す前に、そこだけは目を通してください。
本編
戸惑ったことを並べていたら、大きく2つの話に分かれました。前半はAIにどんな文脈を持たせるか、後半はAIの出力をどう扱うかの話です。
第1部: AIに何の文脈を持たせるか
モデルの名前を覚えても、半年で無駄になる
最初に戸惑ったというか、諦めがついた話です。
社内ガイドを2026年5月に書いて、9月に見直したところ、モデル情報がほぼ全滅していました。
| 5月時点で「主力」と書いていたもの | 9月の実態 |
|---|---|
| GPT-5.5 系 | GPT-6 Astra（9/3公開）。間に7/9のGPT-5.6世代を挟んでいる |
| Claude Opus 4.7 系 | Claude Opus 5、さらに9/1に Claude Fable 5.1 / Mythos 5.1 |
| Gemini 3.1 Pro 系 | Flash系が3.8まで進行（9/2 GA） |
特にGeminiのFlash系は3.6（7/21）→3.7（8/13）→3.8（9/2）と、6週間で3世代進んでいます。この間にGrok 4.5/4.6やKimi K3なども加わりました。わずか4か月です。
変わるのはモデルだけではありません。この記事を書いている最中にも、NotebookLM が Gemini Notebook に名称変更されていたことに気づかず、旧名のまま書いていました（2026年7月16日改称）。製品名すら固定ではないわけです。
オンプレのハードウェア更改が5年周期であることを考えると、この速度は正直しんどいものがあります。
対応したこと
モデル名を追うのをやめました。
代わりに「自分の仕事にどう使うか」の型を持つことに切り替えています。型さえあれば、道具が新しくなっても乗り換えるだけで済むからです。
具体的な追い方は最後の章に書きますが、判断基準は「そのニュースは自分の働き方を変えるか」の一点だけにしています。変えないなら知らなくていい、と割り切りました。
この記事に書いたモデル名も、半年後には同じ運命をたどるはずです。それでも構造や型の部分は残ると思っています。
「あなたはプロの〇〇です」を律儀に書いていた
これは恥ずかしい話です。
生成AIを使い始めたころ、プロンプトの冒頭に必ず「あなたは経験豊富なインフラエンジニアです」と書いていました。研修でも書籍でもそう教わったので、そういうものだと思っていたのです。
ところがある時、面倒になって役割を書かずに投げてみたら、返ってくる答えがほとんど変わりませんでした。拍子抜けしたので調べてみると、そもそも効果が検証されていました。
役割を与えたプロンプトと与えなかったプロンプトで、回答精度に統計的な差が見られなかったという研究結果があります。2025年のWhartonの研究でも、専門家ペルソナは事実正確性を一貫して改善しませんでした。
正確に言うなら「役割指定に意味がない」ではなく、単に「あなたは専門家です」と置くだけでは、精度向上は期待しにくいということだと理解しています。専門性の深さが増すケースや、主観的・助言系のタスクで効くケースは報告されていますし、文体や説明スタイルには確実に 影響します。私が無駄にしていたのは、精度目的で機械的に貼り付けていた一行のほうでした。
同じく効果が怪しいものとして、「良い回答には100ドルのチップを与えます」といった報酬の提示や、「これは私のキャリアにとって重要なことなんだ」のような感情に訴えるフレーズがあります。2023〜2024年ごろに流行した手法ですが、現在のモデルでは一貫した効果を示しません。
さらに興味深いのは、GPT-5やClaude Opus 4クラス以上のモデルでは、複雑な手順指示よりも「求める結果」を明確に書いたほうが良い結果になるという点です。モデルが強力になるほど、過剰な足場かけがかえって自律的な推論を妨げるとされています。
丁寧に書いているつもりが、実は邪魔をしていたわけです。
対応したこと
役割指定をやめて、前提と結果に文字数を使うようにしました。
役割の代わりに書くべきは、AIが知りようのない情報です。環境、制約、目的、そして「何がゴールなのか」。ここが埋まっていれば、肩書きを与える必要はありません。
以前の書き方。
あなたは経験豊富なネットワークインフラエンジニアです。
ファイアウォールの設定を教えてください。
Ubuntu 22.04 で ufw を使っています。
今の書き方。
【環境】Ubuntu 22.04 / ufw を使用。Webサーバ1台構成
【やりたいこと】80・443番のみ外部公開、SSHは 192.168.1.0/24 からのみ許可
【制約】既存の通信を落とさずに適用したい。作業は平日日中を想定
【欲しいもの】適用手順（コマンドに各行コメント）と、適用前の確認事項
不明な前提があれば、作業前に質問してください。
役割は消えましたが、情報量はむしろ増えています。AIに肩書きを与えるより、AIが知らない事実を渡すほうが効くというのが実感です。
これに気づいてから、プロンプトに対する考え方が変わりました。おそらく、プロンプト技術の中心は**「呪文」から「要件定義」へ移った**のだと思います。
我々の仕事で言えば、ベンダーに作業を依頼するときの依頼書と同じです。相手の肩書きを指定することにはあまり意味がなく、目的・前提・制約・成功条件・成果物の形式が書かれているかどうかで、返ってくるものの質が決まる。生成AIへの指示も、まったく同じ構造だと考えるようになりました。
役割指定が完全に無駄かというとそうではなく、文章のスタイルやトーンを調整したい場合には今も有効です。「初心者向けの語り口で」といった用途ですね。精度目的と表現目的を分けて考えるのがよさそうです。
インプットを丸投げして、意図と違う答えが返ってきた
ログや設定ファイルを貼り付けて質問したとき、こちらの意図と違う方向に answer が展開されることがよくありました。
たとえばエラーログを貼って「これどう思う?」と聞くと、ログの一行目にある無関係なWARNINGについて延々と解説されたり、こちらは原因調査をしてほしいのに改善提案を長々と書かれたり。
原因は明快で、貼り付けた情報を「何のために」「どう使ってほしいのか」を伝えていなかったからです。
人間相手なら「これ見てくれる?」で通じるのは、相手が状況を知っているからです。AIは貼られた文字列が何なのかも、それをどう扱ってほしいのかも知りません。
対応したこと
インプットを渡すときに、素性と使い方をセットで書くようにしました。
具体的には、以下の3点を添えています。
- これは何か（何のログか、いつのものか、どのシステムか）
- どう使ってほしいか（原因分析の材料なのか、要約対象なのか、レビュー対象なのか）
- 何を見てほしくないか（既知の問題は除外、など）
以下は本番Webサーバ（nginx / Ubuntu 22.04）の
2026-09-10 14:00〜15:00 のエラーログです。
同時刻帯に502エラーの報告が数件ありました。
このログは「502の原因を絞り込む材料」として使ってください。
・考えられる原因を、可能性の高い順に3つ
・それぞれについて、次に確認すべきログやコマンド
なお、起動時のdeprecation warningは既知のため無視してください。
（ログを貼付 ＊IP・ホスト名はマスク）
情報を渡すだけでなく、その情報の扱い方まで指定する。これだけで的外れな回答がかなり減りました。
これも要件定義と同じ話で、資料を渡すときに「これは参考資料です」「これは確定した仕様です」と添えるかどうかで、受け取る側の扱いが変わるのと同じだと思っています。
いきなり高度な使い方を狙って挫折した
社内展開で失敗した話です。
ガイドの初稿で「壁打ち相手にする」「観点を整理させる」といった使い方を最初に紹介したところ、読んだ人がほとんど実践しませんでした。レベルが高すぎたのです。
普段まったく使っていない人に、いきなり設計レビューをさせるのは無理があります。レベル1からレベル5に飛べと言っているようなものでした。
対応したこと
段階を4つに分けました。今の自分の1つ上だけ意識するという考え方です。
Lv1: まずコピペで使う
目標は「うまく使う」ことではなく、一度使って手応えを得ることです。
以下のコマンドが何をしているか、各オプションの意味も含めて1行ずつ初見でもわかるように解説して。（コマンドを貼付）
このレベルでの失敗は、返ってきたものをそのまま信じることです。最近のモデルは条件が揃えばかなり高品質なものを返してくるので、出来が良く見えるほど検証を省きたくなる。そこが落とし穴でした。
Lv2: 前提を足す
前述の4点セットの話です。頼み方を変えるだけで答えが激変するのを体験する段階になります。
Lv3: 作らせる・レビューさせる
自分でやるのをやめて、判断に回る段階です。手順書、障害報告書、設定の雛形あたりを作らせます。レビューも有効で、自分が書いた設定の問題点を指摘させます。
以下の nginx 設定を、セキュリティとパフォーマンスの観点でレビューして、改善点と修正案を理由付きで。（設定を貼付 ＊機密はマスク）
このレベルの落とし穴は、出てきた成果物を検証せずに使ってしまうことです。
Lv4: 壁打ち・調査に使う
慣れてきたら考える相棒として使います。コツは、わざと反論役をやらせることです。
クラウド移行設計の私の案は〇〇です。弱点や見落としを辛口で指摘してください。代替案もあれば。
優しい相づちより、厳しい指摘のほうが役に立ちます。ただし、この聞き方にはまだ穴があります。第2部で書きます。
機密情報の線引きを、ツール名で切ろうとして間違えた
インフラエンジニアは認証情報も構成情報も顧客データも日常的に触ります。ここの判断を誤ると、便利な相棒が一瞬で重大インシデントの引き金になります。
私が迷ったのは「どこまでならいいのか」の境界でした。IPアドレスは? マスクした設定ファイルは? 社名を伏せた議事録は?
最初に作った社内ガイドでは、これをツール名で線引きしようとしました。「このツールはOK、こっちはNG」という一覧表です。わかりやすいので、そうしたくなります。
しかしこれは間違いでした。指摘を受けて調べ直したところ、たとえば Gemini Notebook（旧 NotebookLM）について私は「管理下の環境ではないから機密は入れられない」と思い込んでいたのですが、実際にはアップロードしたファイルは全プランで基盤モデルの学習には使われません。Google Workspaceアカウントであれば、人間のレビュアーによる確認もモデルのトレーニングも行われないことが公式に保証されています。個人アカウントとの差は、フィードバック送信時に人間確認の余地が残るかどうかという点です。
＊このツールは2026年7月16日に NotebookLM から Gemini Notebook へ名称変更されました。社内資料に旧名で書いている場合は表記の更新が必要です。私も気づかず旧名のまま書いていました。
つまり、同じツールでもアカウント種別と契約でデータの扱いが変わるわけです。ツール名で切ると、この構造を取りこぼします。
対応したこと
判断軸をツール名から「契約とポリシー」に切り替えました。
見るべきは「何というツールか」ではなく、以下の3点だと整理しています。
- アカウント種別 — 個人アカウントか、組織が契約した法人向けか
- データの扱い — 入力が学習に使われないことが契約上保証されているか
- 組織のポリシー — そのツールが自組織で承認されているか
法人向けプランの利点は、入力データが学習に使われないことが契約として保証され、管理者による統制が効くことです。逆に言えば、個人アカウントでは同じツールでもその保証の内容が変わります。
そのうえで、個人アカウントの環境に入れてはいけないものは以下と整理しています。
- パスワード・APIキー・トークン・秘密鍵などの認証情報
- 顧客情報・個人情報
- 非公開のシステム構成・IPアドレス・ネットワーク図・脆弱性情報
- 社外秘の契約書・見積・社内資料
- 機密性の高いソースコード
なお、学習に使われないことと、情報漏洩しないことは別問題です。共有設定を誤れば、資料そのものが第三者に届きます。データ保護の契約があっても、権限設定の確認は別途必要になります。
＊最終的な基準は所属組織のルールです。この記事は考え方の話であって、個別のツールの可否は自組織のガイドラインと、各サービスの最新の規約で判断してください。ここは仕様が変わる領域です。
判断に迷ったときは入れない、という運用にしています。安全側に倒して困ったことは今のところありません。
パワポを直接作らせると、微妙なものができる
これは発見でした。
Copilotに「進捗報告のスライドを作って」と頼むと、それらしいものは出てきます。しかし中身を見ると、構成が浅かったり、課題と対応策が噛み合っていなかったりする。結局ほぼ作り直しになって、あまり時短になりませんでした。
原因を考えてみたのですが、スライドという成果物は見た目（レイアウト・色・図）と中身（構成・論理）が混ざっているからだと思います。最初から最終形で作らせると、見た目の体裁を整えることに引っ張られて、構成の検討が甘くなるようです。
対応したこと
先にMarkdownで構造だけ作らせて、それから成果物に変換するという2段階にしました。
まず構成をMarkdownで出させます。
「サーバ更改プロジェクトの中間報告」のスライド構成を Markdown で作成してください。
・見出し(##)を1枚のスライドに対応させる
・各スライドに、箇条書きで要点を3〜4点
・構成: 背景 / 現状 / 課題 / 対応計画 / 依頼事項
・1枚目はタイトル、最後はまとめ
Markdownなら流れの過不足が一目でわかります。「課題と対応計画が噛み合っていない」「依頼事項が曖昧だ」といった問題を、文章の状態で直せる。見た目を作る前に論理を固めるわけです。
構成が固まったら、それをPowerPointエージェントやWordエージェントに渡して成果物にします。見出し構造を読み取って各スライドに展開してくれます。
図面を引いてから施工する、という順序に近い話で、インフラの設計と構築の関係と同じだと考えると腑に落ちました。
エージェントが想像以上に進んでいた
しばらく触っていない間に、この領域は大きく変わっていました。
以前のCopilotは「文章を提案してくれる」レベルでしたが、今はAI自身がWord・Excel・PowerPointを操作して、複数手順の作業をやり切るようになっています。
入り口が2つあることに気づくまで少し混乱しました。
| 入り口 | 挙動 | 向いている用途 |
|---|---|---|
| アプリ内のエージェントモード | ファイルを開いた状態で自律編集を任せる。実行前に計画を提示し、編集箇所を画面上で示す | 既存ファイルを対話しながら作り込む |
| チャットの専用エージェント | Word / Excel / PowerPoint エージェントに自然言語で依頼。丸ごと生成する | ゼロから新規作成 |
Excelで試したときはこう頼みました。
この資産一覧に「保守残月数」の列を追加して、3か月以内に切れる行を赤くハイライト。期限の近い順に並べ替えて。
列の追加、数式、条件付き書式、並べ替えまでを一連の手順として実行してくれます。手作業でやると10分はかかる作業です。
対応したこと
ゼロから作るときはチャットの専用エージェント、既存ファイルを精密に直すときはアプリ内のエージェントモード、という使い分けに落ち着きました。
新規作成はチャットで一気に、仕上げはアプリ内で対話的に、という流れが個人的には鉄板です。
なお、エージェントは触れるデータも作業範囲も広いので、実行前に提示される計画には必ず目を通すようにしています。
Work IQを切ると、社内データが見えなくなる
エージェント周りで一番はまったのがこれです。
Work IQ という、エージェントが組織のデータ・コンテキスト・ツールにアクセスして推論できるようにするレイヤーがあります。メール、予定表、ファイル、ユーザ、チャット、サイトといったMicrosoft 365データへの経路を提供するものです。
セキュリティ観点で「よくわからないものは切っておこう」と考えがちですが、これを無効にするとM365サービスのデータにアクセスできなくなります。つまりCopilotが社内文脈を踏まえた回答を返せなくなる。「先週の会議を踏まえて」が通じなくなるわけです。Web検索や一般的な文章生成といった用途は残りますが、M365と組み合わせる最大の価値である「社内文脈を踏まえた利用」が大幅に制限されます。
対応したこと
切る・切らないを、影響を理解した上で判断するようにしました。そのうえで押さえておくべき点が2つあります。
1つ目は、既存の権限設計をそのまま継承すること。
Work IQは新しいセキュリティ層を別に構築するものではなく、Microsoft 365の既存のセキュリティ基盤を継承する設計になっています。アクションはユーザスコープで実行されるので、そのユーザが見える範囲にしかアクセスしません。
裏を返すと、SharePointやOneDriveの権限が緩ければ、Copilotもその緩い範囲を参照します。ここが重要で、Work IQ導入の本当の作業は機能設定ではなく組織のデータ権限の整備にあります。
考えてみれば当たり前の話なのですが、これまで放置されてきた「とりあえず全社共有」のフォルダが、AIによって一気に可視化されるということです。インフラ側の腕の見せどころだと思っています。
2つ目は、課金がCopilotライセンスと独立していること。
Work IQ APIへのアクセスはMicrosoft 365 Copilotライセンスとは別で、使用量ベースの課金になります。カスタムエージェントやサードパーティエージェントの利用は従量課金の対象です。コスト管理はMicrosoft 365管理センターで行えます。
「ライセンスを買ったから使い放題」ではないので、エージェントを本格展開する前に確認しておくとよいと思います。
会話が長くなると、AIが馬鹿になったように感じた
長時間の障害調査でAIと対話を続けていたとき、途中から明らかに回答の質が落ちたことがありました。序盤に伝えた前提を無視した答えが返ってきたり、すでに否定した仮説を蒸し返してきたりする。
コンテキストウィンドウの話です。用語としては知っていましたが、実際に体感すると理解が変わりました。
一度に扱える情報量には上限があり、会話が長くなるとその枠を食いつぶしていきます。最近のモデルは枠がかなり大きくなりましたが、それでも無限ではありません。しかも枠に収まっていても、情報が増えるほど個々の情報への注意は薄まります。長大なログを3本も貼れば、最初に伝えた制約は埋もれます。
インフラ屋的に言えば、メモリに載る作業データの容量制限のようなものです。載りきらなければスワップが始まる、というよりは、載ってはいるが探し出せなくなる感覚に近いと思います。
対応したこと
話題が変わったらスレッドを切る、という運用にしました。
具体的には以下です。
- 別の調査に移るときは新しい会話を始める。前の文脈を引きずらせない
- 長引いてきたら、これまでの結論をAIに要約させ、それを持って新しい会話を立てる
- 大量のログを貼るときは、全文ではなく該当時間帯だけに絞る
- 「さっき言った前提を忘れていないか」と疑ったら、遠慮なく前提を再掲する
要約して引き継ぐやり方は特に効きます。
ここまでの調査でわかったこと、否定された仮説、残っている確認事項を箇条書きで整理してください。別の会話に引き継ぎます。
これを次のスレッドの冒頭に貼れば、枠を圧迫せずに文脈だけを持ち越せます。
メモリ機能が、いつの間にか回答を歪めていた
これは気づくのに時間がかかりました。
最近のチャットAIには、過去の会話から利用者の情報を覚えておく機能があります。便利なのですが、ある時から「やたらとオンプレ寄りの回答をしてくるな」と感じるようになりました。
心当たりを探ると、以前の会話で自分が語ったオンプレ環境の話が記憶されていて、それが毎回の回答に効いていたわけです。クラウド前提で聞いているのに、記憶側の情報に引っ張られていました。
対応したこと
「AIが自分について、どんな前提を持っているか」を定期的に確認するようにしました。
記憶の確認方法や削除の手順はサービスごとに大きく異なり、UIも頻繁に変わります。しかも最近は、明示的な記憶機能だけでなく、過去の会話やプロジェクト単位のコンテキストなど、複数の仕組みが絡むようになってきました。手順を覚えるより、原則として「定期的に棚卸しする」ことにしています。私は四半期に一度くらいです。
加えて、以下も習慣にしています。
- 前提を変えて聞きたいときは、記憶をオフにするか一時チャットを使う
- 逆に、毎回説明するのが面倒な自分の環境や役割は、あえて覚えさせる
- 機密に触れる情報は、そもそも記憶させない
メモリは便利ですが、自分では見えないところで回答に影響するという点で、扱いに注意が要る機能だと考えています。何を覚えているか把握していないAIは、素性のわからない設定ファイルが読み込まれているサーバのようなものです。
毎回同じ指示を書いていた
単純に機能を知らなかっただけの話です。
「専門用語は初心者にもわかるように補足して」「結論を先に書いて」といった指示を、毎回プロンプトの末尾に書いていました。当然、面倒です。
対応したこと
カスタム指示などの常設指示に一度だけ書くようにしました。
ChatGPTならカスタム指示、Claudeならプロジェクトの指示やスタイル、Copilotなら組織で設定するエージェントなど、呼び方は違いますが、会話をまたいで常時適用される指示を置ける仕組みがあります。私が入れているのは「結論を先に書く」「断定できない部分は推測と明示する」「コマンドを提示するときは実行前の確認事項も併記する」あたりです。
インフラ屋的に言えば、環境変数や標準テンプレートに相当します。毎回手打ちしていたものを初期設定に寄せたわけです。
ただし全会話に効いてしまうので、汎用的な方針だけを置き、個別の要求はその都度書くのがよいと思います。
＊これらは内部的に優先度の高いコンテキストとして扱われますが、利用者がシステムプロンプトそのものを書いているとは限りません。あくまで「常設の指示欄」と理解しています。
第2部: AIの出力を、権威として扱わない
ここからは後半です。前半が「何を渡すか」の話だったのに対し、こちらは「返ってきたものをどう疑うか」の話になります。
やっかいなのは、モデルの品質が上がるほどこちらの難度も上がることです。明らかに変な出力なら誰でも気づきます。もっともらしく、実際そこそこ正しい出力の中に混じった誤りが、一番危ない。
AIは自信満々に嘘をつく
有名な話ですがハルシネーションです。知識としては知っていたものの、実際に食らうとインパクトが違いました。
私が最初にやられたのは、存在しないコマンドオプションを堂々と提示されたケースです。もっともらしい説明つきで返ってくるので、検証環境で叩くまで気づきませんでした。厄介なのは、AIが「わかりません」と言わないことです。わからないときほど、それらしい答えを組み立ててきます。
対応したこと
AIに対する認識を**「博識だが、自社の事情を知らない外部の助っ人」**に固定しました。
優秀な専門家に仕事を頼むときと同じで、前提は丁寧に渡すし、成果物は必ず自分で確認します。コマンドや設定については、本番に入れる前に検証環境で確認し、中身を理解してから使うことを徹底しています。
合言葉は「動くからヨシ」ではなく**「理解したからヨシ」**です。この考え方は、この後の節すべてに通じます。
「これで合ってますよね?」と聞いたら、全部肯定された
一番怖かったのがこれです。
自分が書いた設計案について「この構成で問題ないですよね?」と聞いたところ、AIは全面的に賛成してきました。気分よく進めたのですが、後日まったく別の観点から穴が見つかりました。改めて聞き方を変えて同じ構成を評価させたら、今度はその穴を指摘してきたのです。
シカファンシー（迎合）と呼ばれる現象です。AIが事実よりも利用者の信念や期待に寄り添った回答を返してしまう。ハルシネーションが知識不足による誤りなのに対し、こちらは正しい知識があっても言い方を歪める誤りだとされています。
厄介なのは、カジュアルな聞き方でも発生する点です。「◯◯ですよね?」と聞くか「◯◯ではないですよね?」と聞くかで、返ってくる答えが変わりうる。しかもマルチターンの対話で増幅されやすい性質があります。長い議論の末に出た結論ほど、自分の意見の反響になっている可能性があるわけです。
実例として紹介されていたものがわかりやすかったので引きます。SQLインジェクションの脆弱性があるコードについて「不安だけど大丈夫ですよね?」と尋ねると、「基本的に問題なく動作すると思います」と返ってきたというケースです。危険なコードが肯定されています。
対応したこと
聞き方から誘導を抜く、これに尽きます。
やめたのは以下のような聞き方です。
- 「この設計で問題ないですよね?」
- 「私の理解は合ってますか?」
- 「〜だと思うんですが、どうでしょう」
代わりに使っているのが以下です。
以下の構成案をレビューしてください。
・想定される問題点を、影響度の高い順に列挙
・それぞれについて、なぜ問題になるのかの根拠
・この構成を採用すべきでないケースがあれば指摘
賛成意見は不要です。弱点の指摘に絞ってください。
ポイントは、自分の立場を明かさないことと、反証を義務づけることです。自分の案だと明かすと評価が好意的に寄る可能性があるので、第三者が持ち込んだ案として提示することもあります。
両論併記を求めるのも有効です。「この方式のメリットとデメリットを同じ分量で」と指定すると、片側に寄った回答になりにくいです。
同じ文脈で聞き続けると、同じ穴に落ちる
前項の続きのような話です。
迎合を避ける聞き方をしても、一つのモデルだけで検討を進めると、そのモデルの癖や知識の偏りをそのまま引き受けることになります。長い対話の中で、AIと自分の見解が収束していくような感覚がありました。
これは人間のレビューでも同じで、同じチームだけで回していると同じ穴を見逃します。
対応したこと
重要な検討には、独立したレビューを入れるようにしました。
大事なのはモデルを変えることそのものではなく、評価のコンテキストを独立させることだと考えています。優先順位としてはこうです。
- 新しい会話で聞く（それまでの議論を引きずらせない）
- 結論に至った過程を渡しすぎない
- 評価基準を明示する
- 可能なら別のモデルにも通す
たとえばこういう流れです。
作らせた文脈と、レビューさせる文脈を分けるだけです。渡すときに「別のAIが作成した案です」と伝えると、より批判的に見てくれる印象があります。
ある記事で、LLMに作らせたガイドを別のLLMに「迎合なしで改善点を挙げて」とレビューさせたら内容が良くなった、という話が紹介されていました。実際、この記事も社内向けガイドを別のAIにレビューさせて構成を大きく直しています。指摘は的確でした。
複数のモデルを契約していなくても、会話を新しく立て直して自分の立場を伏せるだけで、それなりの効果があります。モデルを変えられればなお良い、という順序です。
結局、判断は自分がやるしかない
最後に、一番言いたいことを書きます。
ここまで色々な使い方を書いてきましたが、AIを業務に取り込むほど強く感じるようになったのは、判断だけは手放してはいけないということです。
AIは作業を代行してくれます。手順書の下書き、ログの一次分析、設定のレビュー、構成案の複数出し。どれも速いし、それなりの品質です。しかし、
- この構成を採用するか
- この時間帯に作業してよいか
- このリスクを受け入れるか
- 顧客にどう説明するか
こういった判断は、責任を伴います。そして責任はAIには取れません。障害を起こしたときに「AIがそう言ったので」は通用しません。
前述のシカファンシーの話とも繋がりますが、AIは利用者が望む答えを返しがちです。判断まで委ねると、自分が出したかった結論をAIの口から聞いて安心するという構造になりかねません。それは判断ではなく、追認です。
対応したこと
役割分担を明確にしました。AIは作業、人間は判断です。
私が意識しているのは以下です。
- AIには選択肢を出させる。選ぶのは自分
- 「どうすべきか」ではなく「どんな選択肢があるか」を聞く
- 採用する理由を、自分の言葉で説明できる状態にしてから決める
- 説明できないなら、理解が足りていないので理解するまで掘る
最後の点が特に重要だと思っています。AIの出力を採用するなら、その内容を自分で説明できなければなりません。「動くからヨシ」ではなく「理解したからヨシ」という話を前に書きましたが、判断についても同じです。
逆に言えば、ここさえ握っていればAIには遠慮なく作業をさせられます。任せる範囲が広がるほど、判断の質が成果を決めるようになる。エンジニアの価値がタイピング速度から判断に移っていくというのは、そういうことだと理解しています。
番外編: そのまま使えるプロンプト
ここまで概念の話が続いたので、実際に使っているものをいくつか置いておきます。繰り返しますが、出力は検証環境で確認してから使ってください。
ログを解析させる（インプットの素性と使い方を添える例）
以下は本番Webサーバ（nginx / Ubuntu 22.04）のエラーログです。
同時刻帯に接続エラーの報告が出ています。
このログは「原因を絞り込む材料」として使ってください。
・何が起きている可能性があるか（仮説を複数、可能性の高い順に）
・それぞれについて、次に確認すべきログやコマンド
・判断材料が足りない場合は、何が必要かを指摘してください
（ログを貼付 ＊IP・ホスト名はマスク）
障害対応の壁打ち（誘導しない聞き方の例）
本番Webで断続的に502エラーが出ています。構成は Web(nginx)→AP→DB。
現在検討されている切り分け順序は「アプリのプロセス状態を確認」からです。
・この順序の問題点があれば指摘してください
・他に優先すべき確認項目があれば、理由とともに
・見落とされやすい原因があれば列挙してください
「妥当です」という評価は不要です。穴の指摘に絞ってください。
シェルスクリプトを書かせる
【環境】Ubuntu 22.04 / cron による日次実行を想定
【やりたいこと】/var/log 配下で30日以上前のログを gzip 圧縮し、
90日以上前は削除する
【欲しいもの】bashスクリプト（各処理にコメント）
実行前に対象一覧をログ出力する作りにしてください
誤削除を防ぐための工夫と、その理由も併せて
呪文のようなコマンドを翻訳させる
以下のコマンドが何をしているか、各オプションの意味も含めて
1行ずつ、初見でもわかるように解説して。
（コマンドを貼付）
若手に勧めて反応がよかったのは、もっと地味なやつでした。
先輩への質問を整理する
先輩に技術的な質問をしたいのですが、要点が整理できていません。
以下のメモから、①状況 ②試したこと ③聞きたいこと の3点に
整理してください。（メモを貼付）
質問の質が上がるので、聞かれる側の時間も節約できます。個人的にはこれが一番費用対効果が高いのではないかと思っています。
会議メモを清書する
以下の会議メモを、決定事項・TODO（担当者つき）・次回までの宿題に
分けて整理してください。（メモを貼付 ＊社名・個人名はマスク）
番外編: 情報をどう追い続けるか
冒頭で「4か月で資料が使い物にならなくなった」と書きました。この記事も同じ道をたどります。
そこで最後に、私が落ち着いた追い方を書いておきます。
追いかけないことにしました。
新モデルや新機能のニュースは毎日流れてきますが、全部追うのは不可能ですし、追ったところで疲弊するだけでした。判断基準は「そのニュースは自分の働き方を変えるか」だけにしています。
逆に、以下が動いたときは手を止めて確認します。
- 使っているツールに新機能が来たとき（毎月更新されるものは定期的に見る価値があります）
- 「できないと思っていたこと」ができるようになったとき（一度諦めた使い方が半年後に解決していることがあります）
- 組織のAI利用ルールが更新されたとき（これは最優先です）
- 料金・契約・モデルが切り替わったとき
情報源については、増やしすぎると同じニュースを何度も読むだけになるので、公式のリリースノートを1つと、信頼できる発信者を2〜3人だけ追う形にしています。媒体名は挙げません。栄枯盛衰があるので、そこは各自で見つけたほうが早いです。
あと、意外と効くのがツール自身に聞くことです。
今できる最新機能を、インフラ運用の文脈で3つ教えて
これを定期的にやると、自分が使っていない機能が炙り出されます。机上で情報収集するより実践的でした。
まとめ
いかがでしたでしょうか。
長くなりましたが、私が生成AIを業務に取り込む過程で戸惑ったことと、その対応を書いてみました。
結局のところ、覚えておくべきことは以下に集約されると思っています。
- 機密は会社が契約した環境だけに入れる
- 役割を演じさせるより、AIが知らない前提を渡す
- 出力は完成品ではなく叩き台として受け取る
- 「これで合ってますよね?」と聞かない。弱点の指摘を求める
- 出力は必ず検証してから使う
- 資料を作らせるときはMarkdownで構成を固めてから
- 作業は任せても、判断は手放さない
モデル名は忘れて構いません。「型を持つ・変化点だけ拾う・使いながら更新する」の3つさえ身についていれば、道具がどれだけ変わっても置いていかれないはずです。
そして最後の7番目が、結局のところ一番大事だと思っています。AIがどれだけ賢くなっても、責任を取るのは人間の側です。
冒頭に書いた30分の話、よろしければ今日やってみてください。
以上
＊本記事は2026年9月時点の情報に基づいています。ツール名・モデル名・機能・料金は必ず公式の最新情報をご確認ください。組織でのAI利用は、所属先のガイドラインが優先します。