AIエージェントの「見えなさ」が気持ち悪い ブラックボックスとの現実的な付き合い方を考える：及川卓也からエージェント時代の開発者たちへ（3）（2/2 ページ）

[及川卓也，Tably株式会社]

AIエージェント時代の「新しいログ」の必要性

　ここまで見てきたように、AIエージェントでは「何を考え、どう判断しているのか」という肝心な部分が見えにくく、従来のように原因をたどる手がかりを得にくい状況があります。

　では、本当はどんな情報があれば、エージェントの行動を後から理解できるのでしょうか。

　実は、エージェントの行動を理解するには、概念的にいえば 次の5つの視点 が必要になります。

• どんな情報を材料として受け取ったのか（入力）
• それをどう整理・理解したのか（推論）
• 最終的にどこへ向かおうとしていたのか（意図）
• 実際にどんな行動を選んだのか（行動）
• その結果、世界や画面がどう変わったのか（結果）

　なお、この5つは前回触れたOODA（Observe／Orient／Decide／Act）の流れにもゆるやかに対応しています。つまり、エージェントが「何を見て（Observe）」「どう解釈し（Orient）」「どんな方向性を選び（Decide）」「どう動いたのか（Act）」という意思決定の流れを、後から追えるようにするための視点ともいえます。

　さらに、この5つは前回扱ったAIブラウザの失敗の原因ともはっきり対応しています。例えば──

• 入力の段階で誤った情報を読み取っていた可能性があります。実際、私が観察していた範囲でも、本文の見出しをリンクだと誤認してクリックしたような挙動がありました。
• 推論の段階で文脈理解がずれていた可能性もあります。不要なページへ飛んだのは、タスクの目的と関係のない情報を重要だと判断した結果かもしれません。
• 意図が正しく保たれていなかった可能性もあります。途中で本来のタスクから外れるような行動が見られましたが、これは「何を目指しているのか」が内部で揺らいだ兆候とも考えられます。
• 行動の選択が適切でなかったケースもありました。必要な操作を飛ばして別の工程に進んだり、突然ページを戻ったりと、一貫性のない動きが見られました。
• 結果が意図した状態と異なっているのに気づかないまま進んでしまった可能性もあります。誤ったページに到達しても“成功した”と判断して次へ進む場面がありました。

　つまり、なぜ迷走しているのか分からないように見えるのは、この5つのどこが失敗したのかが一切見えないところから生じていたわけです。

　そして現状では、この5つのどれも十分には明かされません。入力が見えないし、推論は隠されている、意図はつかめず、行動は断片的で、結果だけが断続的に提示される。このように可視化が不完全なままでは、どこでつまずいたのかを後からたどることができません。言い換えれば、トラブルシューティングに必要な材料が揃っていない状態なのです。

では、私たちは何ができるのか

　ここまで読むと、「結局ブラックボックスを受け入れるしかないのか」と感じるかもしれません。しかし、完全に手をこまねいている必要はありません。サービス側の内部ログには触れられなくても、ユーザーや開発者の立場から「コントロール感」を取り戻す工夫は幾つかあります。

　まず、もっとも手軽なのはプロンプト設計による事前コントロールです。ゴールや前提条件、制約をあらかじめ明示し、「どういう手順で進めてほしいのか」「途中経過をどう出力してほしいのか」といったメタな指示まで含めて書く。ブラックボックスの中身は見えなくても、入口と出口を整えることで、挙動のブレをある程度抑えることができます。

　例えば、私は以下のような「書き方のルール」を設けることが多いです。

• 段階的に考える　「この問題を解決するために、考えたことをステップごとに書き出し、最終的な答えにたどり着くまでの思考過程を詳しく説明してください」
• 理由と選択肢の提示　「なぜその答えを選んだのか、他にどんな選択肢があり得るかも併記し、それぞれの根拠を述べてください」
• ReAct方式の模倣　ReAct（Reasoning + Action）は、LLM（大規模言語モデル）が「考える（推論）」ことと「動く（行動）」ことを行き来しながらタスクを進める考え方です。内部で何が起きているかは見えなくても、その流れを「型」として外に書き出させることで、判断の筋道を追いやすくします。
  「次のフォーマットを使って応答してください。
  Step 1: Question（あなたが考えた疑問・課題）
  Step 2: Thought（どのように考えたか）
  Step 3: Action（とった行動や推論）
  Step 4: Observation（得られた情報・気づき）
  Step 5: Answer（最終的な結論や応答）」

　もちろん、こうした指示を出したからといって本当の内部ログが取れるわけではありません。でも、少なくとも「何を根拠にそう言ったの？」を後から問い直せる形にはできます。

　うまくいったプロンプトや失敗したプロンプトを自分なりに記録しておくことも、立派な自前ログになります。

　次に有効なのが、後追いのためのログを自分で持つことです。チャット履歴を保存しておき、「どの指示に対して、どんな応答が返ってきたのか」を後から振り返れるようにする。実務で使う場合なら、AIアシスタントの操作履歴や監査ログを、チーム側でも保管するルールを決めておく。サービスの内部ログは見えなくても、自分の手元に疑似ログを残すだけで、状況はかなり変わります。

　さらに一歩進むなら、フィードバックと評価で　外側から締めるというやり方もあります。変な出力が出たら放置せず、「どこがダメだったのか」をメモしておく。同じ指示を複数回、あるいは複数のモデルで試し、どこまで結果がブレるのかを自分なりに把握する。これは、LLMをただ使う側ではなく、評価する側になるアプローチです。

　そして開発者であれば、観察可能な自作エージェントを持つという選択肢もあります。LangChainや各種SDKを使い、ツール呼び出しや中間プロンプトをトレースできる形でエージェントを組む。あるいはLLM Observability系のツールを使って、「見えることが前提」のエージェントを自分で作る。理想を言えば、ブラックボックスをそのまま受け入れるのではなく、自分で観察できる箱を1つ持つということです。

　ここまで工夫すれば、少なくとも「業務で使う上での納得感」はかなり高めることができます。

　完璧な可視性の実現は、まだ手探りの段階です。しかし、何も見えない状態で使い続けるのと、工夫を凝らしてAIエージェントと付き合うのとでは、得られる安心感や学びの量が大きく異なります。私は、ただ「分からない」ことに耐えるのではなく、少しでも自分の手でコントロールを取り戻す道を選びたいと考えています。これこそが、AIエージェントを活用する側として持つべき心構えであり、AIに「使われる側」にならないために不可欠な要素だと信じています。