第3回で、AIは主役ではなく補助に回す、という方針を書きました。今回はその設計思想を、もう一段深く掘り下げます。なぜAIに全部を答えさせず、確認観点の補助だけに絞るのか。三つの理由に分けて整理します。

最初にはっきりさせておきたいことがあります。現時点のOpsMate Proは、外部のAIには接続していません。実装されているのは、ローカルのルールによる補助だけです。以下は、実際にAIをつなぐ場合にも保ちたい設計方針、として読んでください。

1. ハルシネーションの影響を、できるだけ小さくする

生成AIには、もっともらしいけれど誤った内容を出してしまう（ハルシネーション）性質があります。存在しない設定項目、誤ったAWSの仕様、不要または危険な変更、確認していない原因の断定。これらが、いかにも正しそうな文章で出てくることがあります。

やっかいなのは、利用者がその誤りを見抜けるとは限らないことです。とくに、確認観点を持っていない担当者ほど、AIの断定を信じてしまいやすい。第1回で書いた「その課題の常識を知らない人」ほど、誤答に引っぱられる危険があります。

ここで断っておくと、ハルシネーションを完全に防ぐことはできません。それは技術的に無理だと思っています。だから狙いは「防ぐ」ではなく、「誤答が課題全体へ与える影響を小さくする」ことに置きました。

具体的には、AIに最終判断や課題の完了を任せません。確認観点、正常例、異常例、完了条件といった、判断の骨組みは課題データの側が持ちます。AIに任せるのは、確認漏れの指摘、判断の例、質問の例、証跡の候補といった補助だけです。仮にAIが一部で誤っても、完了の可否は課題データと完了制約が握っているので、誤りがそのまま課題全体を狂わせにくい、という構えにしています。

2. APIへ渡す文脈を、限定する

二つ目は、AIに渡す情報の範囲です。将来AIをつなぐとしても、課題全体や全履歴を毎回渡すことはしたくない、と考えています。

渡すのは、今のステップに必要な最小限にとどめます。現在の課題、現在のステップ、そのステップの目的、必要な確認観点、そして利用者の最低限の入力。逆に、無関係な証跡や機密情報は渡しません。

理由は二つあります。一つは、余計な文脈を渡すほど、回答が無関係な方向へ広がりやすくなること。もう一つは、機密になりうる情報を必要以上に外へ出したくないことです。実際、共通モデルのStepには、右の補助欄へ渡す文脈を持たせる aiContext というフィールドを最初から用意してあります。渡す範囲を、データの構造の側であらかじめ絞っておく、という発想です。

3. AI APIの従量課金を、抑える

三つ目は、お金の話です。ここは正確に書きます。よく「APIキーに課金される」と言われがちですが、そうではありません。APIキーを利用して呼び出したAI APIの、入力・出力トークンなど、利用量に応じて従量課金が発生する、というのが正しい理解です。

この観点で見ると、設計の判断は費用に直結します。課題全体を毎回送れば入力トークンが増えます。長文の回答を生成させれば出力トークンが増えます。ステップを進めるたびにこれが積み上がり、利用者数と課題数が増えるほど、費用の見通しは立てにくくなります。

だから、費用を抑える方向は、そのまま先ほどの「文脈を限定する」とつながります。

  • 課題全体ではなく、現在のステップだけを渡す。
  • 回答の形式を、短い確認観点に限定する。
  • 目的や正常例のような固定情報は、AIに書かせずローカルのデータから表示する。
  • AIが要らない場面では、そもそもAPIを呼ばない。
  • APIが未設定のときや失敗したときは、ローカルの補助へ切り替える（フォールバックする）構想にしておく。

こうしておけば、使用量と費用が予測しやすくなります。AIを主役にせず脇役に置くという方針は、品質の面だけでなく、費用の面からも理にかなっている、というのが今の考えです。

現時点の実装は、ローカル補助だけ

ここまで方針を書いてきましたが、繰り返します。今のOpsMate Proは、実際のAIには接続していません。右の補助欄で動いているのは、外部に何も送らない、決定的なローカル補助です。

コードの冒頭には、その位置づけをはっきり書いてあります。

// 右AI補助欄のローカル応答（AI未接続）
// これは外部AI APIを呼ばない「ローカル・ルールベース」の補助です。
// 実装済みのAIチャットに見せないこと。応答は現在ステップのマスタデータから生成する。

export const AI_MODE_LABEL = 'AI未接続（ローカル補助）'

補助欄には、この「AI未接続（ローカル補助）」というバッジを常に表示しています。応答は、質問のキーワードから現在ステップの該当箇所（手順・確認値・正常例・異常例・注意・証跡など）を引いて返すだけの、決まった動きです。生成AIではありません。

だから、次のような言い方はどれも当てはまりません。AIチャットを実装済み、OpenAIへ接続済み、Claudeへ接続済み、Bedrockへ接続済み、BYOK（利用者が自分のAPIキーを持ち込む方式）を実装済み、ハルシネーション対策が完成、API費用の削減を実証した。いずれも、現時点では事実ではありません。

作ってみて感じたこと

正直なところ、AIをつなぐ前にここまで役割と文脈を細かく決めておくのは、少し回り道に見えるかもしれません。でも、後からつなぐときに「どこまで任せるか」を決めていないと、ずるずると全部を任せてしまいそうだ、という不安がありました。

だから今回は、実接続を急ぐより先に、AIの担当範囲を限定する方針をデータと画面の側に埋め込んでおくことにしました。将来AIをつなぐとしても、確認観点の補助という役割に絞る。その土台だけは、ローカル補助の段階で作っておいた、という位置づけです。

次回は、ここまでの設計を3つの課題すべてに載せてみて、共通化がどこまで通用したのかを検証します。テストの数字や、フレークへの対処もあわせて書きます。