第6回 番外編：この検証から得た、ほかの開発プロジェクトでも使えるTipsと学び
連載：Decision-1をRAGに組み込む：設計・検証・運用の実践・第6回・番外編 ｜ 連載のまとめ
Microsoft-Decision-1を検索拡張生成（RAG）へ組み込む検証では、回答品質の比較以外にも、多くのつまずきがありました。日本語の文字化け、途中で止まるAPI処理、レビューしづらい画面、遅れて反映される費用です。これらへの対処は、別のモデルやデータを使うプロジェクトにも応用できます。
この記事は、2026年10月16日から20日の検証から得た学びをまとめた番外編です。各項目では、実際に起きたことと、そこから提案できる設計を分けています。個々のサービスやツールの制限を、一般的な仕様として紹介するものではありません。[1]
1. モデルの前に、入力の品質を検査する
起きたことと対処
日本語文書をトークン単位で分割すると、一部のチャンクの両端に置換文字U+FFFDが入りました。6,118件のうち310件、約5%が対象でした。文字の途中で切れた端を修正し、チャンクIDを保ったまま差分だけを再埋め込みしています。
同じ検証では、文書を途中まで取り込んだために、ある話題が丸ごと抜ける問題もありました。検索精度の問題に見えても、実際には探す本文が保存されていないことがあります。
他のプロジェクトで使うなら
取り込み時に、文字化け、空本文、異常に短い文書、主要な話題の欠落を検査する方法が考えられます。すべての品質を自動で判定するのは難しくても、検出した入力の不備を次の処理へ流さないことで、モデルの比較に入力不良が混ざるのを減らせます。
差分更新では、本文のハッシュ、文書ID、チャンクIDを役割に応じて使い分けます。本文の変更を検出しても、根拠ラベルが指すIDの意味が変われば、評価データも確認し直す必要があります。IDを固定するだけで再現性が保てるわけではありません。
2. 根拠の全文を確認できるレビュー画面を作る
起きたことと対処
質問レビューを表計算の一覧で進めようとしましたが、短い抜粋だけでは根拠が足りるか判断しにくく、作業が進みませんでした。そこで、質問、模範解答、根拠、周辺の断片、検索結果へすぐ移動できるコマンドラインのレビュー画面を作りました。
AIの一次レビューを初期表示にし、人が提案と理由を読み、採用または変更する形にしました。判定は1問ごとに保存し、途中から再開できるようにしています。
他のプロジェクトで使うなら
人の確認作業を減らしたいときは、承認ボタンの数より、判断に必要な情報へ戻る手間を見ます。抽出結果なら元文書の該当箇所、分類なら判断理由と境界事例を同じ画面から読めると、確認しやすくなります。
AIの提案を初期値にすると速く進む一方、提案に引きずられる可能性もあります。高い採用率だけをレビュー品質の証拠にせず、提案と異なる判断も入力しやすくし、理由を記録します。
今回は、その場でレビュー用のツールを作成しました。必要に応じて要件を満たすツールを準備することが非常に容易になったのは、AIを使って作業を進める大きな利点だと思います。
3. 長い処理は、再開できる単位で保存する
起きたことと対処
評価は数時間かかり、APIの待ち、端末の再起動、作業用AIの利用制限で中断し得る処理でした。質問IDと構成ごとに結果を追記し、済んだ処理を飛ばして再開できるようにしました。
検索結果、判定値、生成へ渡した根拠、回答も保存しました。その結果、追加評価では検索と判定を繰り返さず、生成モデルだけを差し替えられました。
他のプロジェクトで使うなら
抽出、分類、移行などの大量処理でも、再実行の単位を業務上のIDと対応させると、中断の影響を限定できます。保存のタイミングは、費用が発生する外部呼び出しや、長い処理の区切りに置くと効果があります。
ただし、条件が異なる結果を、同じ実行の結果として混ぜない設計が必要です。モデル、プロンプト、入力データ、設定を実行IDと結び付けます。再開時に条件が違えば別の実行にする、という方法が考えられます。これは今回のログ再利用から広げた設計上の提案です。
今回の検証では、状況を把握するために、AIに何度もログを参照してもらう場面がありました。ログや作業実績を細かく残すことは手戻りを避けるのに有効ですが、AIに繰り返し読み直してもらうと、非常に多くのトークンを消費しやすくなります。作業前の設計段階で、状況の把握に必要なログ参照を最小限にできるよう意識しておくと効果的だと思います。
4. 待ち時間と失敗の種類を分けて記録する
起きたことと対処
並列数だけを抑えても、毎分のリクエスト枠を超えて再試行が続くことがありました。開始間隔も制御し、クォータの待ちとAPI応答時間を別に記録しました。あるモデルでは応答が長く止まる例もあり、観測した正常応答時間を基にタイムアウトを調整しています。
出力にも失敗がありました。意味のない繰り返しが上限まで続く回答は、HTTP上は成功でも、業務上は利用できません。ステータスコードに加え、出力上限への到達や本文の異常を数えました。
他のプロジェクトで使うなら
| 記録する時間・状態 | 分かること |
|---|---|
| 呼び出し前の待ち | キューやクォータで詰まっているか |
| API応答時間 | 外部処理や通信に時間がかかっているか |
| 再試行回数と理由 | 制限、サーバーエラー、タイムアウトのどれか |
| 出力の検査結果 | 成功応答でも内容が使えないか |
| 処理全体の時間 | 利用者が実際に待った時間 |
再試行は回数や待ち時間に上限を設け、失敗した入力を後から調べられるようにします。タイムアウトを短くすれば常に改善するわけではなく、正常な長い処理まで打ち切る可能性があります。代表的な入力の分布を見て選ぶ必要があります。
5. 費用には取得時刻と集計範囲を添える
起きたことと対処
Azureの費用は、使用直後と時間を置いた取得で値が変わりました。取得結果を時刻付きで保存し、請求への反映済み額と、トークン数からの未反映見積もりを分けました。途中資料と後の表には内訳の不一致も残り、記事化では同じ時点の集計を使って照合しています。[2]
他のプロジェクトで使うなら
金額には、対象期間、通貨、取得時刻、対象リソース、実績か推定かを添えます。合計と内訳を載せるなら、同じ範囲の数値から作ります。キャッシュ、割引、未反映分がある状態で、料金表の単価から計算した値を、請求額と同一視しないようにします。
実行中の制御と後日の照合も分けます。実行中は処理件数やトークン数で上限を管理し、後から費用記録と照合する方法です。通知に遅れがある場合でも、処理側の上限なら、どこまで実行するかを直接制御できます。
6. 都合の悪い結果と計画変更を残す
起きたことと対処
Phi-4-mini-instructで出力不良が多く起きたとき、都合のよい回答が出るまで作り直すことはしませんでした。主結果を残し、上限到達回答を除いた値は参考値として分けました。
構成も当初の計画から変わりました。クラウドDBを作らず、ローカルDBで評価しています。計画図を実施図として使うと、存在しないリソースや、測定していない通信経路まで実施済みに見えてしまいます。
他のプロジェクトで使うなら
実行結果には、正常時だけでなく異常件数を残します。除外するなら、対象、理由、除外前後の件数を示し、主結果との関係を明確にします。
文書では「計画」「実施」「未実施」を分けます。短い変更記録でも、変更理由と比較への影響があれば、後から結果を読む助けになります。説明をきれいにするために履歴を消すと、再現に必要な条件も失われます。
7. AIに作業を依頼し、人の判断に必要な材料を残す
今回の実装、実行、記録の多くはClaude Codeと進めました。人は分野、予算、構成の選択、質問のレビュー、結果の解釈を担当しました。作業を依頼する際は、タスクと完了条件を示し、進めながらログと文書を更新する方法を使っています。
うまく進んだのは、単に作業量を任せた場面だけではありません。「抜粋では判断しにくい」「費用が少なすぎる」といった具体的な問題を伝え、レビュー画面の作成や生データの調査につなげた場面です。
他のプロジェクトでも、AIに作業を頼む単位と、人が判断する単位をそろえる方法が考えられます。たとえば「モデルを比較する」だけで終えず、「同じ質問の差を保存し、失敗例を説明できる状態」を完了条件にします。
AIが書いたレポートも、ログや集計と照合する対象です。実装が動いたこと、指標が上がったこと、業務に採用できることは、それぞれ別の判断です。人が根拠へ戻れる記録と道具を用意することが、ほかのプロジェクトでも使える学びでした。
参考資料
資料の確認日：2026年10月23日。対処は今回の環境での経験であり、製品の普遍的な制限や性能を示すものではありません。
- Decision-1 RAG評価検証・資料リリース（筆者、2026年10月22日版）。「03_計画からの変更点と理由」「06_学びとTips」「07_作業レポート」とレビュー画面を参照。
- Azureの使用料（筆者、確認時のコミット）。費用照合の根拠。