はじめに
こんにちは！CTO室のmk0812です。
弊社では、医療クリニック向けプラットフォーム「paylight X」において、LINEを通じた患者からのメッセージに対してAIが自動で返信する機能があります。システムの全体像は簡潔ですが、下記のように構成されています。
上記フロー図の通り、患者様がLINEでメッセージを送ると、Webhookを経由してそのメッセージを受け取り、AI基盤を介してLLMに問い合わせます。LLMは返信メッセージの生成だけでなく、予約の作成や変更といった具体的なアクションの要否も判断します。
この仕組みの中でAIの判断プロセスがブラックボックス化するケースがあります。
- エラーが発生した際、「なぜAIはこの予約をキャンセルだと判断したのか？」を後から追いかける術がない
- エラーは発生していない際でも、「なぜこのパターンで通常とは異なるケースになったのか？」といったAIそのものの思考が解析できない
Anthropic社の「Tracing the thoughts of a large language model」より
These strategies are encoded in the billions of computations a model performs for every word it writes. They arrive inscrutable to us, the model’s developers. This means that we don’t understand how models do most of the things they do.
とある通り、「モデルがなぜその出力をしたのか」を完全に説明できる状態ではなく、内部推論の可視化（Interpretability）は今まさに研究途上にある、ということが明示があります。下図は同記事の引用ですが、最終的な回答が正しく見えても、その内部では必ずしも“正しい推論”をしているとは限りません。Anthropic社はこの問題を「Faithful reasoning（忠実な推論）」と「Motivated reasoning（望ましい結論に合わせる推論）」と呼んでいます。
引用: Faithful Reasoning と Motivated Reasoning の対比（Anthropic）
（出典：Anthropic, “Tracing the thoughts of a large language model”）
そのため現時点では、モデル内部の完全理解を待つよりも、プロダクション運用では入力・判断・出力を記録して「後から追える状態」にすることが現実的な解決策と考えております。つまり、「AIの判断プロセスがブラックボックス化して、可観測性が欠如している」という問題に対して、ログ設計を後付けの運用工夫ではなく、システム設計の一部として最初から組み込むことが不可欠だと思います。
本記事では、この「AI運用における可観測性の欠如」を解消するために私たちが構築したDynamoDBを活用したログ設計の実践例を紹介します。
課題：AIブラックボックス問題とは
AI（LLM）をプロダクションで運用する際、上記で挙げた通り以下の3つの観点で「ブラックボックス = 中身が見えない」問題が発生します。
運用面：問題発生時に原因が追えない
例えば弊社のケースだと「〇〇医院の〇〇さんの予約がうまくいかなかった」という問い合わせがあったとき、何が起きたのかを調査する必要があります。しかし、AIが何を入力として受け取り、何を出力したのかがわからなければ、原因特定は不可能です。
改善面：プロンプト改善のためのデータがない
AIの精度を上げるにはプロンプトの改善が必要です。しかし、「どんなケースでAIが間違った判断をしたか」のデータがなければ、改善の方向性が定まりません。
監査面：Input/Outputの整合性チェックができない
LLMは時に、入力された患者IDとは異なる情報を出力に含めてしまうような、予期せぬ挙動（ハルシネーション等）をすることがあります。こうしたデータの不整合を検知し、後から監査できる仕組みがなければ、医療という信頼性が求められるドメインでの運用はリスクが伴います。
解決策：役割の異なる2つのログ基盤
これらの課題を解決するため、私たちはログを**「守りの調査」と「攻めの改善」**の2つの役割に分離して設計しました。
1. 監査・エラーログ（Audit Logs） — 「守り」のログ
目的: 異常発生時の即時調査、およびデータの整合性監査。
システムが予期しない挙動をした際や、LLMからの回答が業務ルールに抵触した際に、その「現場の証拠」を記録します。
-
主な記録内容
- 一意のセッション/リクエスト識別子
- 発生タイミング
- エラーの分類（通信失敗、タイムアウト、パースエラー、業務ロジック不整合など）
- その時の入力データと出力データのスナップショット
これにより、「いつ、どのユーザーに対して、なぜその判断が下されたのか」を即座に特定し、迅速なリカバリーを可能にします。
2. 思考ログ（Thinking Logs） — 「攻め」のログ
目的: LLMの回答精度向上とプロンプトエンジニアリングのためのデータ蓄積。
正常系を含めた全ての推論プロセスを記録します。
-
主な記録内容
- LLMに渡された最終的なプロンプト（システムプロンプトや変数展開後の全文）
- LLMからの生レスポンス（JSON構造など）
- 推論に要した時間やトークン使用量などのメタデータ
このログをBigQueryやAthenaで分析することで、「特定の質問パターンで回答が不安定になる」といった傾向をデータに基づいて特定し、プロンプト改善の確かな根拠として活用します。
設計のWhy（なぜこうしたか）
キー設計の考え方
ログの検索性を高めるため、以下の2つの軸でデータを整理しています。
- エンティティ識別子 (Partition Key)
- 調査の起点となる単位（ユーザーIDやセッションIDなど）をキーにします。これにより、特定のユーザーで問題が発生した際に、関連するログを即座に集約できます。
- 時系列 (Sort Key)
- イベントの発生日時をソートキーにすることで、一連の推論プロセスを時系列順に追跡可能にします。
なぜNoSQL（DynamoDB）を採用したか
-
スキーマの柔軟性
- プロンプトエンジニアリングやモデルのバージョンアップを重ねるたびに、LLMの入出力仕様は少しずつ変わる
- RDBのような固定スキーマではマイグレーションが必要になるが、NoSQLはスキーマを定義せずにデータを保存できるため、仕様変更があっても既存ログと新しい形式が共存可能。
-
スケーラビリティとコスト
- 思考ログはすべてのLLM呼び出しを記録するため、ユーザー数が増えるとすぐに膨大なデータ量になりうる。
- DynamoDBなら高速な書き込みに対応でき、TTL（有効期限）機能で一定期間後のデータを自動削除すれば、ストレージコストも抑えられる。
運用での活用イメージ
エラー発生時の調査フロー
- Slack等にエラー通知が届く（識別子、発生時刻を含む）
- ログ基盤から該当する識別子で検索
- 入出力のスナップショットを確認し、LLMの判断ロジックやデータの不整合を確認
- 原因を特定して対応
上記の操作を属人化しないようにRunbookを置いています（AIによるエラーケースは入出力によって変わる可能性があるので、その度に随時アップデートをしつつ最新を保っています）。
プロンプト改善サイクル
thinking_logsを定期的に分析し、以下のサイクルを回す想定で組んでいます。
-
データ収集:
thinking_logsをBigQuery/Athenaにエクスポート - パターン分析: エスカレーション（AIが人間対応と判断）が多いケースを特定
- プロンプト改善: 問題パターンに対応するようプロンプトを修正
- 効果測定: 改善後のエスカレーション率を確認
次なるステップ：品質の可視化と自動評価
ログ基盤が整った後のステップとして、**自動評価（Automated Evaluation）**の導入も視野に入れています。単にログを保存するだけでなく、「その回答が適切だったか」を機械的にスコアリングすることで、改善サイクルをさらに加速させることができます。
例えば、Langfuseのようなツールを活用することで、以下のような指標を可視化できます（参考: LLMの品質を可視化！Langfuseで実現する自動評価システムの構築）。
- Context Precision（コンテキスト精度）: RAGにおいて、検索したドキュメントが質問に対してどれだけ適切だったか
- Faithfulness（忠実性）: 生成された回答が、検索したコンテキストに基づいているか（ハルシネーションしていないか）
これらをダッシュボードでモニタリングすることで、「なんとなく良くなった」ではなく「数値として改善した」と言える状態を目指します。
高度な可観測性プラットフォームの活用
今回はAWSのマネージドサービス（DynamoDB）を組み合わせて自前でログ基盤を構築しましたが、システムが複雑化し、複数のエージェントが連携するような構成（Multi-Agent System）になった場合は、専用のObservabilityプラットフォームの導入も検討に値します。
例えば、Datadog LLM Observabilityなどは、LLMアプリケーションのトレースを分散トレーシングのように可視化し、複雑なチェーン処理のどこで時間がかかっているか、どこでエラーが起きているかを直感的に把握できます（参考: Datadog LLM ObservabilityでAIエージェントを可視化してみる）。
フェーズに合わせて、自前構築の柔軟性と、専用ツールのリッチな機能を使い分けていくのが良いでしょう。
まとめ
今回のログ設計を通じて得た学びをまとめます。
- 「なぜ？」に答えられる仕組みを最初から作る: AIの判断は確率的です。だからこそ、決定的なログ（Input/Output）を残すことが、ブラックボックス解消の第一歩になります。
- 「守り」と「攻め」でログを分ける: 障害調査のためのログと、精度向上のためのログでは、求められる鮮度や保存期間が異なります。目的を明確に分けることで、運用がシンプルになります。
以上となります。AIシステムを開発・運用されている方にとって、この記事が「信頼されるAIサービス」を作るための一助となれば幸いです。
参考
Discussion