【ITニュース解説】Tutorial: Show the Serving Tier Beside Every AI Draft

今日のITの世界では、AIが文章やコードのドラフト（草稿）を生成することが一般的になっている。しかし、AIが作ったものを人間が確認し承認する際、一つ大きな課題がある。それは、「このAIドラフトは、どのAIモデルが、どのサーバー環境で生成したのか」という情報が、レビューする人には見えないことが多い点だ。これは、単に承認する人が不注意なのではなく、システム設計そのものに問題がある。AIの生成物の出所が不明なままでは、承認者はその内容を信頼する根拠を持てず、まるで目隠しをして承認ボタンを押しているような状態になってしまう。

この記事では、AIが生成したドラフトの信頼性を高めるため、その「出所」を示す証拠、具体的には「サービングティア」（AIが動いている環境やモデルの情報）をUI（ユーザーインターフェース）に表示する仕組みを、エンドツーエンドで構築する方法を解説する。

まず、MonkeyCodeというオープンソースのAIコーディングプロジェクトを例に挙げるが、このプロジェクトが提供する「無料モデルアクセス」「無料サーバーオプション」「1000万トークン提供」といった宣伝文句は、鵜呑みにするのではなく、一つ一つ「検証すべき主張」として扱う姿勢が重要だ。プロダクトの設計は、未検証の「事実」に基づいて行うべきではない。

この情報表示の仕組みを構築するためには、いくつかの段階を踏んでいく。

ステージ0：最初に主張ファイルを記述する プログラミングを始める前に、AIサービスのプロバイダーから提供された情報、例えば「無料ティアの利用が可能か」「どのような条件か」といった主張を、一つ一つファイルに記録する。この記録には、情報の出典と、まだ検証されていないことを示す「checked: never」といったステータスを含める。これにより、後で何が検証済みで、何が未検証なのかを明確にすることができる。特に、トークン数のような数値は変動しやすいため、書面で記録しておくことが重要だ。

ステージ1：一度エンドポイントを調査する 次に、実際にAIのAPIエンドポイント（AIが提供する機能にアクセスするためのURL）にリクエストを送り、AIからの生の応答データを取得する。Node.jsのような実行環境で「fetch」関数を使い、AIモデル名、APIキー、ベースURLといった情報を環境変数から安全に取得・利用するスクリプトを作成する。そして、AIに「この条項を一行で要約して：14日以内に返金」のような指示を送り、その結果として返ってくるJSON形式のデータ（HTTPステータスコード、使用されたAIモデル名、応答の終了理由、消費トークン数、応答にかかった時間など）を記録する。このとき、AIの応答が期待通りでなかった場合（例：モデル名が不明、終了理由が不明など）も、「unknown」としてそのまま記録することが肝心だ。推測で補完すると、本来見せるべき情報が隠されてしまうことになる。

ステージ2：ティアのレシートを描画する 取得した生の応答データをもとに、AIが生成したドラフトのすぐ下に、その「出所」を示す情報表示ストリップ（レシートのような表示）をUIとして描画する。このストリップには、「利用したティアの種類（無料ホスト型など）」「使用モデル」「応答の終了理由（正常終了、または途中で切れたなど）」「応答にかかった時間」「コンテキストの状況（要求した内容がAIに完全に伝わったか、途中で切れてしまったかなど）」といった情報を、簡潔で分かりやすい言葉で表示する。専門用語ではなく、例えば「無料共有モデル」のように、レビューする人が直感的に理解できる表現を用いることが重要だ。また、エラーや不明な状態も隠さずに表示することで、その表示が「形だけのもの」になるのを防ぐ。

ステージ3：調査前に停止条件を記述する このレシート情報がただ表示されるだけでは不十分だ。表示された情報に基づいて、人間がAI生成物を承認する際の「停止条件」（つまり、この情報を確認したら承認を一旦停止すべきケース）を事前に定義する。例えば、「AIの応答が途中で途切れていた（truncated）ことを、レビュアーが2回連続で見逃した場合、承認プロセスを停止する」「応答が12秒以上遅延した場合、レビュアーが承認ボタンを押す前に警告する」といった具体的なシナリオと、それに対する測定項目、停止条件を設定する。これにより、UIが正しく機能しているか、レビュアーが情報を活用できているかを客観的に評価できる。

ステージ4：リカバリーパスを描画する AIが生成したドラフトに問題があったり、レビュアーがAIの応答に疑問を感じたりした場合に、スムーズに人間による修正や介入に戻れる「リカバリーパス」（回復経路）を設計することが不可欠だ。具体的には、「人間による修正に戻す」（hand-back）ボタンをワンクリックで操作できるように配置し、この操作を行っても、AIが生成したドラフトの内容が失われないようにする。もし、この「戻す」作業が煩雑で入力の手間がかかるようだと、レビュアーは面倒がって、問題があるドラフトでもそのまま承認してしまう可能性が高まる。これはユーザーの訓練で解決する問題ではなく、設計で解決すべき問題である。

ステージ5：アクセシビリティを確認する 作成した情報表示ストリップは、AIの承認という重要な意思決定を支援するものであるため、全てのユーザーにとって「到達可能」で「読みやすい」ものである必要がある。スクリーンリーダー（視覚障がい者がコンピューター画面の情報を音声で聞くためのソフトウェア）を使ってテストを行い、ティア情報が色だけでなくテキストでも読み上げられるか、途中で途切れた（truncated）という情報がアイコンだけでなくアクセシブルな名前（スクリーンリーダーが読み上げる情報）にも含まれているか、タブキーによるフォーカス移動で「人間による修正に戻す」ボタンにスムーズに移動できるか、エラーメッセージが適切に紐付けられているか、表示のコントラストが十分かなどを確認する。単にログのような専門的な情報ではなく、人間が聞いて理解できる言葉で表現されているかも重要だ。

ステージ6：感情ではなく証拠に基づいて決定する 最終的に、これまで収集した証拠と検証結果に基づいて、「無料ティアのAIモデルをプロダクトに採用するかどうか」といった重要な意思決定を行うための明確なルールを設定する。例えば、「レシートにティア、モデル、終了理由が正確に表示されるなら条件付きで採用」「不明な状態がUIで明確に表示され、テストも可能なら条件付きで採用」「人間による修正への戻し機能がオフラインでも動作し、ドラフトを保持できるなら採用」といった具体的な基準を設ける。もし、これらの重要な情報がUIに表示されず、ログファイルの中にしか存在しないのであれば、それはレビュアーのためではなく、開発者のための情報でしかない。レビュアーが何の根拠もなく承認している状態は、設計上の大きな問題であると理解すべきだ。

この一連のプロセスは、AIモデルの「質」そのものを評価するものではない。AIがどれほど優れた文章を生成するかを測るものではなく、AIと人間の共同作業において「インターフェースがどれだけ正直に情報を提供しているか」を測定し、人間が適切な判断を下せる環境を整備することに焦点を当てている。人間による承認ステップがないシステムや、AIが生成したドラフトが外部に出ないシステムでは、この手順は不要かもしれない。しかし、人間がAIの生成物を承認する場面がある限り、その「出所」を示す透明な情報提供は、システムの信頼性を高める上で極めて重要な要素となる。MonkeyCodeのようなツールを使って実際に試してみて、あなたが作る「レシート」が、AIが何をしたかを明確に語っているか、ぜひ確認してみてほしい。レビュアーが何の根拠もなく承認している状態は、設計上の大きな問題であると理解すべきだ。