雨上がりの朝、青葉商店の業務改善担当、佐伯ユイは、営業担当に届いた問い合わせの返事を画面で見つめていた。社内AIアシスタントは、見積書の確認や社内資料の検索をすばやくこなし、文章もきれいに整えている。それなのに営業の高橋は、その返事を閉じて、倉庫の在庫表と古い契約書を探し始めた。
「答えは自然なのに、どうして使えないの?」
画面に残っているのは、最後に生成された回答文だけだった。どの資料を検索したのか、RAGが何を拾ったのか、どのツールを呼び、権限やエラー処理で何が起きたのかは見えない。サプライチェーンDXを進める青葉商店で、ユイはプロンプトだけでなく、AIエージェントの動いた道筋そのものを追う必要に気づき始めていた。
この記事の答え
- 結論生成AIの利用ログを処理全体で追跡すれば、サプライチェーンDXの改善テーマを見つけられます。
- 根拠検索資料やRAG、ツール、権限、エラー処理までトレースすると、回答の失敗箇所を特定できます。
- 最初の一歩まず入力から最終回答まで、参照資料の版とツール操作、エラー経路をシナリオ単位で記録します。
第1章:朝の画面に残る、きれいな返事

第1章:朝の画面に残る、きれいな返事 - 本文
雨上がりの朝、青葉商店の事務所で、佐伯ユイは営業担当の高橋に届いた問い合わせの返事を見つめていた。窓の外では、濡れた道路が白い光を返していた。
社内AIアシスタントが作った文章は、ていねいだった。商品の納期と出荷条件も、自然な言葉で並んでいる。文章だけを読めば、すぐに送信してよさそうな返事だった。
「答えは自然なのに、どうして使えないの?」
高橋は返事の画面を閉じた。隣の机から倉庫の在庫表を取り出し、引き出しの奥にあった古い契約書まで広げ始めた。
「この商品、今は倉庫に残っていないんです。しかも、取引先との新しい契約では、出荷の条件が変わっています」
ユイは高橋の手元をのぞいた。AIの返事には、在庫がある前提の文があった。契約書に書かれた新しい条件は、どこにも反映されていなかった。
「送る前に気づけてよかった。でも、どこで間違えたのかしら」
ユイは社内AIアシスタントの利用画面を開いた。そこに残っていたのは、問い合わせへの最終回答だけだった。入力した指示文も、検索された資料も、回答の途中で呼ばれた在庫確認の仕組みも表示されない。
検索が失敗したのかもしれない。古い契約書を新しい資料として拾ったのかもしれない。権限が足りず、在庫データを読めなかった可能性もあるのに、画面にはその気配がなかった。
「この返事のどこを直せばいいの?」
ユイの声に、高橋は古い在庫表から顔を上げた。
「文章を直すだけでは、また同じことが起きそうですね」
その言葉が、ユイの胸に小さな石のように残った。これまでは、AIが最後に出した文章を保存できれば、利用の記録は足りると思っていた。しかし今朝の返事には、文章になる前の道のりが隠れていた。
ユイはシステム担当の中野に連絡した。中野は青いマグカップを持って、ユイの席までやって来た。
「AIのログって、最後の答えを保存するだけではないんですか?」
「それだけだと、今回のような失敗は追えません。まず、処理が始まった時の入力を見ます。それから、どの資料を検索したか、何を答えの材料にしたか、どの道具を動かしたかをつなげて見るんです」
中野は画面に簡単な線を描いた。質問から検索へ、検索から在庫確認へ、そこから回答へ。一本の線の途中に、古い資料や権限エラーがあれば、そこだけ色が変わるようにした。
「RAGという仕組みは、社内文書を探して、見つけた内容をAIの回答に混ぜます。だから、答えだけでなく、何を拾ったかも記録しないと、資料の古さや取り違えが見えません」
ユイはうなずいた。AIが前の会話を覚えて使うメモリも、外部の在庫システムを呼ぶツールも、途中で止まった時のエラーも、返事の裏側にある。
「つまり、AIが何を言ったかではなく、どうやってそこへ着いたかを見るんですね」
「そうです。処理の始まりから終わりまでを、一つの記録として残します」
中野が見せた開発中の画面には、OpenTelemetryの名前があった。処理の区切りに目印を付け、複数のサービスを通った道筋をつなぐ仕組みだと、中野はやさしく説明した。
ただし、何でもそのまま残せばよいわけではなかった。顧客名や価格、契約内容には、見てよい人の範囲がある。入力文や検索結果を記録するなら、隠す部分と保存する期間も決めなければならない。
机の端には、IPAの「テキスト生成AIの導入・運用ガイドライン」が置かれていた。ユイはその表紙を見てから、ノートを開いた。
最初の行に、こう書いた。
「問い合わせ一件。最終回答だけでは、失敗の場所がわからない」
高橋は新しい契約書を閉じ、ユイのノートを見た。
「次の返事は、いっしょに道筋を見ながら作れますか?」
「ええ。まず、どの資料を拾い、どの道具を呼び、どこで立ち止まったのかを見つけましょう」
雨雲が去った窓の向こうで、倉庫へ続く道が乾き始めていた。画面に残ったきれいな返事は、答えではなく、見えない道を探すための入り口になった。
第2章:見積書のすき間から、見えない失敗が顔を出す

第2章:見積書のすき間から、見えない失敗が顔を出す - 本文
午後、営業の高橋が、雨の名残をつけたままユイの席へ急いできた。手には一枚の見積書と、青い付箋の貼られた契約書がある。AIは金額と品名を正しく照合したのに、大切な契約条件を一つ見落としていた。
「ユイさん、この見積書、本当に問題ないって出たんですか?」
高橋が画面を指さした。そこには、社内AIアシスタントの返事が残っている。
「金額、品名、数量を確認しました。問題ありません」
けれど、契約書には、納品後三十日以内に検収を終えるという条件があった。見積書には、その条件と違う日付が書かれている。金額は合っていても、取引を左右するすき間が残っていた。
ユイはAIの履歴を開いた。見えているのは、最後に作られた文章だけだった。どの契約書を検索したのか、社内資料を探すRAGが何を拾ったのか、どの部分を比べたのかは、画面の外に隠れていた。
「答えはきれいなのに、確認の道が見えない……」
そのとき、別の案件のログが目に入った。営業担当が納期を尋ねた会話で、AIは社内文書検索ツールを何度も呼び出している。同じような検索語を繰り返し、最後は権限エラーの表示で止まっていた。
しかも、利用者の評価欄に残っていたのは、短い一言だけだった。
「回答が違う」
その言葉だけでは、古い資料を使ったのか、検索に失敗したのか、見られない文書を求めたのかが分からない。ユイは画面の小さな文字を追いながら、胸の奥が少し重くなるのを感じた。
そこへ、システム担当の神谷がやって来た。神谷は黙ってログを横に並べ、見積書の画面と検索履歴を見比べた。
「プロンプトが悪いとは限らないよ。AIに何を頼んだかだけでなく、どの資料を検索したか、ツールにどんな引数を渡したか、どの操作を許可されていたか、失敗した後にどう動いたかも見ないといけない」
「引数というのは、ツールに渡す細かな指示ですね」
「そう。たとえば、納期を探すなら、商品名だけで検索したのか、契約番号や改訂日まで渡したのかで結果は変わる。権限がなければ、AIは答えられない。それなのに、最後の文章だけを見ると、全部が一つの失敗に見えてしまうんだ」
神谷の声は、倉庫の棚を一段ずつ確かめるように落ち着いていた。ユイは、AIを一人の新人に重ねた。報告書だけを読んで叱るのではなく、どの棚を見て、誰に尋ね、どこで迷ったのかをたどる必要がある。
二人は、見積書の確認を一つの場面として書き出した。入力は営業から届く見積書と契約書、確認する項目は必須項目の有無と関連書類との一致に分ける。最後の回答だけでなく、検索資料、照合結果、エラー、利用者の修正まで一つの流れに並べることにした。
「必須項目があるかと、別の資料と合っているかは、別々に見たほうがいいですね」
「うん。金額が合っていても、納品条件が違うことはある。二つを分ければ、どこで抜けたのかが見えやすい」
神谷は、その確認の流れを小さなテスト台に置いた。同じ見積書を二度渡し、同じ質問を入力する。すると一度目は契約条件の不足を指摘し、二度目は「問題ありません」と返した。
「同じ入力なのに、答えが揺れています」
「生成AIは、毎回まったく同じ道を通るとは限らないからね。検索結果の順番や、使う資料の組み合わせで返事が変わる。だから、正解率だけを一つの数字で見るより、実際のシナリオを何度も再現して、どの場面で揺れるかを見るほうがいい」
シナリオとは、入力から回答までの一続きの場面のことだと、神谷はやさしく言い直した。見積書を受け取り、資料を探し、条件を照合し、必要なら営業へ確認を返す。その一連の動きを、同じ条件で何度も確かめるのである。
ユイは、AIの利用ログをただ保存するだけでは足りないと気づいた。ログは、失敗を責める記録ではない。次にどの資料を整え、どの権限を見直し、どの検索を直せばよいかを教える、小さな足あとだった。
帰る前に、ユイはIPAのテキスト生成AIの導入・運用ガイドラインを開いた。導入だけでなく運用も考える資料を手元に置き、デジタル庁の生成AIの業務利用に関する報告書も並べた。
「明日から、回答だけでなく、AIが歩いた道を記録してみます」
ユイは新しい確認表を作った。最初の欄には、こう書いた。
「見積書の答え。検索した資料。使ったツール。許可とエラー。人が直した場所」
窓の外では、雲の切れ間から夕日が差していた。画面に残った「問題ありません」という文字は、もう結論ではなかった。その奥にある見えない道をたどるための、最初の印になっていた。
第3章:神谷が見せた、一本の長い足あと

第3章:神谷が見せた、一本の長い足あと - 本文
夕方、青葉商店の会議室には、雨上がりの光が細く差していた。神谷は照明を落とし、大きな画面に、ひとつの問い合わせ処理を映した。
「今日は、答えではなく、答えができるまでの道を見よう」
画面の上には、要求ID「REQ-0417」、受付時刻「16:12:08」、会話の履歴、実行IDが並んでいた。高橋が入力した「関西倉庫の在庫を確認し、納期を営業へ返して」という文と、AIが作った回答も見える。
その下には、細い線が何本も伸びていた。社内文書検索、在庫管理システムへの問い合わせ、権限確認、エラー処理、そして最後の回答生成が、枝のようにつながっている。
「この一連の足あとを、トレースと呼ぶんだ」
神谷が画面の一本の線を指でなぞった。
「トレースは、問い合わせ一件分の道のりだよ。その中にある一つひとつの動きは、スパンと呼ぶ。たとえば、文書を探した動き、APIを呼んだ動き、権限を確かめた動き。それぞれを別々に見られるから、どこでつまずいたかが分かる」
「最終回答だけなら、一行で終わります。でもトレースなら、その一行の前に何があったかをたどれるんですね」
「そう。AIエージェントは、ひとりで答えを思いついているわけじゃない。資料を探し、道具を使い、結果を見て、次の動きを選んでいる。その順番が見えないと、直す場所も分からない」
ユイは最初の検索スパンを開いた。検索語は「関西倉庫 納期」。取得資料の一覧には、今年の物流条件表のほかに、「2022年度 物流契約補足資料」が混ざっていた。古い資料の更新日には、赤い印が付いている。
「この古い資料が、回答の根拠になっています」
「回答文は自然でも、情報源が古ければ営業は使えないね。ここでは、プロンプトを直す前に、検索結果の順位と資料の有効期限を見る必要がある」
神谷は、検索スパンの横に小さなメモを付けた。「情報源:古い契約資料」。続けて、在庫管理システムを呼び出したスパンを開くと、権限確認のあとに一度エラーが起きていた。AIは再試行し、別の経路で在庫表を取得していたが、その事実は最終回答に書かれていなかった。
「失敗したけれど、最後は答えが出ています。これは成功と呼んでよいのでしょうか」
「利用者が知らないままなら、危ない成功だね。再試行した結果が正しいか、権限が足りなかった理由は何か。そこまで確認しないと、同じ失敗が別の倉庫で起きる」
別の要求IDを開くと、今度は正しい納期表が検索されていた。ところが、その直後のスパンには、ツールの返した「納期未確定」という結果を十分に読まず、AIが「通常三営業日」と回答を作った記録が残っていた。
神谷は、文章を作るAIをLLMと呼ぶこと、その前に資料を探して渡す仕組みをRAGと呼ぶことを説明した。難しい言葉を使ったあとで、すぐに言い直す。
「つまり、正しい本を見つけても、読まずに返事を書けば間違える。検索の問題と、道具の結果を読む問題は、別々に直す必要があるんだ」
ユイはノートを開き、改善候補を横に並べた。プロンプト、情報源、RAG検索、ツール、メモリ、権限、エラー処理、回答表現。回答の言葉だけを直すのではなく、どのスパンに手を入れるかを置き場所ごとに分けた。
「評価の星も、要求IDと結びつけましょう。星が少ないとき、検索の失敗なのか、曖昧な指示なのか、権限の問題なのかを分けて見たいです」
神谷はうなずき、画面の評価欄を開いた。ところが、「星一つ」で絞り込んでも、該当するトレースは表示されなかった。評価の記録に要求IDはあったが、実行IDが保存されていなかった。
「足あとを見つけたのに、靴と持ち主が結びついていません」
「小さな穴だけど、ここを埋めるのが大事だね。評価を送るときに、要求ID、実行ID、評価、自由記述を一緒に保存しよう。個人名や商品名は必要な範囲だけにして、画面に出す前に隠す」
ユイはテスト用の問い合わせを一件送り、回答の下にある評価ボタンを押した。次に実行IDをコピーし、評価記録とトレースを照合した。今度は、星一つの理由と、その直前に起きた権限エラーが同じ画面に並んだ。
神谷は、OpenTelemetryに合わせた項目名を確認しながら、記録の形を整えた。要求IDで全体を探し、トレースを開き、スパンを時刻順に見る。必要ならGrafanaの画面から一覧を出し、似た動きをする問い合わせを同じ棚に置く。
一件だけでは、たまたまの失敗かもしれない。そこで二人は、営業、購買、倉庫から集まった複数のトレースを並べた。古い資料を選ぶもの、権限エラー後に別の道へ逃げるもの、ツール結果を読まずに答えるものが、少しずつ同じ形にまとまっていった。
「遅延が長いものだけを集めるのではなく、いつもの道から外れたものを探すんですね」
「そう。エラー率が低くても、間違った資料を選ぶ動きが続けば、現場には困りごとが積もる。監視は、止まったかどうかだけでなく、普段と違う歩き方を見つけるために使うんだ」
会議室の外では、倉庫のシャッターがゆっくり閉まり始めていた。ユイは、社内の閉じた環境からログを外へ出さないこと、必要な項目だけを残すことを確認した。
机の端には、IPAの『テキスト生成AIの導入・運用ガイドライン』が置かれていた。神谷はページを閉じずに言った。
「導入した日が終わりではない。使われ方を見て、運用を直すところまでが仕事だよ」
その夜、ユイは新しい確認表を作った。回答文の横には、情報源、検索、ツール、権限、エラー処理の欄がある。翌朝、高橋がまた問い合わせを送ると、ユイは答えを読む前に、一本の長い足あとを開いた。
第4章:GitHubの小さな箱と、消えたログの行方

第4章:GitHubの小さな箱と、消えたログの行方 - 本文
青葉商店では、ユイと神谷が、AIの返事だけでなく、返事までの道のりを一つの記録にまとめ始めた。前は画面に残った文章を見て、よさそうかどうかを考えていた。今は、その文章がどの資料と道具から生まれたのかを追えるようにしようとしていた。
朝の会議室には、白い紙が何枚も並んでいた。ユイは紙の左から、要求ID、時刻、ユーザーの入力、AIの出力を書き、右側に参照した情報源、使ったツール名と引数、許可の有無、ツールの結果、エラーの内容を並べた。神谷は、LLMの呼び出しとツールの呼び出しを同じ流れで見るため、OpenTelemetryのGenAI向けの考え方を参考にしていた。
「答えだけを見ていたら、途中で何が起きたかは分からないね」
「うん。検索が空振りしたのか、古い資料を拾ったのかも、同じ返事に見えるかもしれない」
二人が試しにログを集めると、画面の中に顧客名がそのまま現れた。契約書の条件も、営業担当が入力した相談文も、きれいに並んでいた。便利な記録箱を作ったつもりが、開ければ何でも見えてしまう箱になっていた。
ユイは画面から目を離せなかった。神谷は、ログに残す前に顧客名や契約の細部をマスキングし、誰が見られるかを分ける必要があると話した。保存する範囲と期間を決め、閲覧した人の記録も残すことになった。外部にデータを出さない閉じた環境での生成AI利用を扱うRUTILEAの検証報告書も、神谷の机の端に置かれていた。
「全部残せば、全部見えてしまうんだね」
「だから、調べるために必要なものだけを残す。見てよい人も、見た記録も決めるんだ」
その午後、ユイは高橋のパソコンに保存されたプロンプトを見せてもらった。そこには、現在使っている文章はあったが、なぜ直したのか、前の版で何が起きたのかは残っていなかった。小さな修正が積み重なり、いつの間にか誰も道筋を説明できなくなっていた。
神谷はGitHubにプロンプトのテンプレートを置いた。使い方の説明と、実際に使う文章を分け、変更した日と理由を記録する場所も作った。やがて、プロンプトだけでなく、RAGの検索条件、ツールを呼んでよい範囲、失敗したときの分岐も、同じ履歴の中に並んだ。
「文章を変えたのか、検索を変えたのか、それとも許可の設定を変えたのか。そこが分かるだけで、話し合い方が変わるね」
「うん。直した人の記憶ではなく、残った履歴を見て考えられる」
二人は、営業の在庫確認、倉庫への出荷依頼、古い契約書の照会という代表的な業務シナリオを用意した。同じ入力を何度か試すと、AIの答えは毎回まったく同じにはならなかった。そこで、文章の美しさだけでなく、どの情報源を選んだか、どのツールを何回呼んだかも並べて比べた。
最初のテストでは、返事の文を整えることに夢中になった。文章は読みやすくなったのに、検索元の契約書が古いままだった。さらに、同じ在庫確認のツールを重ねて呼んでいる記録も、トレースを広げて見るまで見つからなかった。
「文章を直す前に、どの道を通って答えたのかを見ないといけないね」
その言葉のあと、会議室の空気が少し軽くなった。問題が一つの答えに隠れているのではなく、検索、許可、ツール、エラー処理がつながった道のどこかにあると、二人の目がそろってきたからだ。ユイはIPAの『テキスト生成AIの導入・運用ガイドライン』を閉じ、GitHubの小さな箱に新しい履歴を保存した。
翌朝、高橋は生成された返事をすぐに閉じなかった。画面の横にあるトレースを開き、参照先とツールの動きを確かめてから、倉庫の在庫表に手を伸ばした。まだ仕組みは育ち始めたばかりだったが、青葉商店には、答えを直すだけではなく、答えが生まれた道を直す時間が流れ始めていた。
第5章:低い評価の束から、直す順番が見えてくる

第5章:低い評価の束から、直す順番が見えてくる - 本文
朝の会議室には、問い合わせ対応、見積書確認、社内文書検索のトレースが並んでいた。壁のモニターには、利用者の低い評価がついた処理だけが淡い赤で表示されている。ユイは紙の束を一枚ずつ机に置き、神谷はその横で、AIの動きをあとから追える記録を開いた。
「まず、答えの文章を見ます。でも、そこだけでは終わりません」
ユイが開いた問い合わせ対応では、返事は自然だった。けれどRAG検索は、倉庫の古い在庫表と期限の切れた契約書を拾っていた。AIエージェント、つまりAIが順番に道具を選ぶ仕組みは在庫確認のツールを呼んだが、権限エラーのあと、その失敗を明らかにせず返事を続けていた。
「RAGは、資料を探して答えに添える仕組みです。トレースには、何を探し、どの資料を使い、どこで止まったかが残ります」
神谷の指先が、時刻の並んだ線をなぞった。テレメトリとは、AIの動きやエラーを後から追える記録のことだと、前の検証で二人は確かめていた。回答文の下に、検索結果、ツール呼び出し、権限、復帰処理がつながっている。
見積書確認の束には、別の赤い印があった。指示が曖昧で、納期と適用する単価を確認する項目が抜けている。その一方で、必要のない在庫照会まで何度も呼び出していた。社内文書検索では、メモリという会話の前提を残す仕組みが、前の取引先名を今の質問へ引き継ぎ、根拠の文書も示していなかった。
ユイは赤い文章を拡大した。画面の最後にある返事だけを見て、整えたい気持ちが浮かんだ。
「最初に、語尾を整えます。読みやすくすれば、印象は変わりそうです」
「待ちましょう。利用者が困った場所に近い順に直します」
神谷は、画面の赤を検索、指示、ツール、権限、メモリ、根拠の六つに分けた。似たトレースを重ねると、古い資料を拾う問題は、問い合わせだけでなく見積書確認にもあった。ひとつの不具合が、倉庫、営業、経理の別々の机に同じ影を落としていた。
ホワイトボードには、重要度、発生頻度、業務への影響、再現しやすさ、修正の難しさが並んだ。二人は「直せそうな順」ではなく、出荷や契約の判断を誤らせる恐れが大きく、何度も起き、同じ条件で確かめられるものから上に置いた。まず古い資料を除き、版と有効日を検索条件に加えることにした。
次に、確認項目を指示文へ明記した。権限エラーなら安全な代替処理へ進み、無理なら「要確認」と残す。会話のメモリは引き継ぐ範囲を絞り、根拠資料を回答のそばに示し、必要のないツール呼び出しも止めることにした。
「正しい答えかどうかだけでなく、根拠を開けるか、安全な権限で動いたか、余計な道具を使っていないかも見ます」
机の端には、IPAのテキスト生成AIの導入・運用ガイドラインと、閉じた環境での利用を扱うRUTILEAの検証報告書が置かれていた。神谷は、異常動作の監視は一度きりの点検ではなく、使い続けるための仕組みだと話した。
修正のあと、二人は同じ問い合わせ、同じ見積書、同じ社内文書のシナリオをもう一度走らせた。回答が正しいか、資料と一致するか、許された権限だけで動いたか、途中で処理が揺れないかを、トレースの線で確かめた。文章がきれいになっただけでは、赤い印は消えなかった。
数日後の営業席では、高橋がAIの返事をすぐ転記せず、横に出た根拠資料を開いていた。古い契約書なら、版の日付を見て閉じる。迷う案件には、「要確認」と書かれた小さな印が残る。
経理の席からも声が届いた。ユイは振り返り、画面の端に残る確認欄を見た。
「AIが決めないものが、前より見つけやすくなりました。人が見る場所が、ちゃんと残っています」
夕方、会議室のモニターから赤い束が消えた。ユイは空いた机に新しい評価の紙を置き、神谷は次に起きた動きが追えるよう、記録の線を静かに確かめていた。
第6章:夕方の画面に、明日の小さな違和感が灯る

第6章:夕方の画面に、明日の小さな違和感が灯る - 本文
夕方、青葉商店の事務所では、ユイの画面に今日の問い合わせの流れが静かに並んでいた。回答文の横には、検索した資料、使ったツール、許可された操作、処理の終わり方まで細い線でつながっている。
以前の画面に残っていたのは、きれいに整った答えだけだった。今は一件の問い合わせがたどった道全体を、Traceという記録で追えるようになっている。
「Traceは、一件分の旅の記録です。中の細かな足跡は、Observationと呼んでいます」
神谷がそう説明すると、ユイは画面をゆっくり下へ動かした。検索、社内のベクトルストアからの資料取得、回答の生成、後処理、返却という順に、どこで何が起きたかが見えていた。
そこへ営業の高橋が、紙の束を抱えてやってきた。少し前まで倉庫へ走っていた人の顔に、夕方の明るさが戻っている。
「今日は、根拠になった資料をすぐ開けました。お客さまに返す前に、品番と納期を自分で確認できたんです」
経理の森も、隣の席から画面をのぞいた。回答の最後には、確認できない項目を人へ戻した印が残っている。
「判断できないものが、ちゃんと人のところに戻ってきました。無理に答えを作らないので、かえって安心できます」
ユイは、社内で使う可観測性の画面を提供するLangfuseの一覧に目を移した。多くの線はいつもの順に並んでいたが、一つだけ、配送予定を確認する前に在庫照合のツールを呼んだ記録があった。
赤い警告ではない。けれど、いつもとは違う動きとして、薄い黄色の印がついている。
「これは失敗ですか?」
「まだ事故ではないよ」と神谷は答えた。「直すテーマは、失敗したあとだけに現れるわけではない。いつもと違う道を歩いたときにも見えるんだ」
ユイはそのトレースを保存し、確認するシナリオをメモした。納期を尋ねる場合、在庫だけを尋ねる場合、権限のない資料を求められた場合を、同じ道で試すことにした。
夕方の光が薄くなるころ、ユイは新しいプロンプトをGitHubの共有リポジトリへ登録した。変更理由には「在庫照合を先に呼んだ経路を確認するため」と書き、試したシナリオと、人が確認した結果も一緒に残した。
そのとき、倉庫から資料更新の知らせが届いた。新しい出荷ルールが社内資料に加わったのだが、更新した直後にAIの回答へ反映されるとは限らない。
「資料を置いただけでは、検索の棚に並ばないことがあります」とユイは言った。「再クロールは、AIが資料を読み直して棚を更新する作業です」
神谷はうなずき、資料の更新時刻、再クロールの完了、回答への反映を順に記録する欄を追加した。高橋が試しに新しいルールを尋ねると、回答には参照資料への道が残り、森がその場で内容を確かめた。
窓の外では、雨上がりの道路に夕焼けが細く光っていた。事務所の照明が一つずつ消えるなか、ユイの画面には新しい問い合わせの線が伸びていく。
その線は、答えだけへ向かうものではなかった。検索の棚を通り、許可の扉を確かめ、ときどき見慣れない道を照らしながら、明日の手直しが始まる場所まで続いていた。
関連キーワード
著者について
鈴木信弘(SNAMO)
鈴木信弘(SNAMO)- 静岡県を拠点に活動する総経験19年のフルスタックエンジニア。AI時代の次世代検索最適化技術「レリバンスエンジニアリング」の実装者として、GEO(Generative Engine Optimization)最適化システムを開発。2024年12月からSNAMO Portfolioの開発を開始し、特に2025年6月〜9月にGEO技術を集中実装。12,000文字級AI記事自動生成システム、ベクトル検索、Fragment ID最適化を実現。製造業での7年間の社内SE経験を通じて、受注システム自動化による業務時間の短縮や検品作業のデジタル化など、現場の課題を技術で解決してきた。富山大学工学部卒、基本情報技術者保有。
プロフィールを見るよくある質問
Q1生成AIの利用ログからサプライチェーンDXの改善テーマを見つけるにはどうすればよいですか?
Q2生成AIの回答が自然なのに間違っている原因は何ですか?
Q3AIの利用ログには何を記録すべきですか?
Q4OpenTelemetryは生成AIの改善にどのように役立ちますか?
Q5生成AIの誤回答を再現して改善する方法はありますか?
Q6AIの利用ログを分析すると、どのような改善テーマが見つかりますか?
Q7生成AIの改善課題はどのような基準で優先順位を付ければよいですか?
Q8サプライチェーン業務で生成AIを安全に活用するために必要な管理は何ですか?
関連記事

生成AIで変わる業務手順の影響範囲を見つめ直す方法
生成AIで変わる業務手順の影響範囲は、回答作成から業務全体へ広げて見直す。入力情報、根拠資料、確認者、記録先、システム、契約、例外時の責任まで影響するためだ。今日の業務を入力・処理・出力・確認に分解し、担当者と利用システムを付せんで整理する。
読む
生成AI導入の損益分岐点を業務単位で見つける方法
生成AI導入の損益分岐点は、業務ごとに効果額がコストを上回る時点である。導入前後の時間や件数に加え、利用料と確認・修正・承認工数まで比較するためである。まず対象業務に業務IDを付け、導入前後の処理時間と確認・修正工数を記録する。
読む
情シス担当者が生成AIとRAGで障害切り分けを短縮するまで
生成AIとRAGを使えば、情シスの障害切り分けを短縮できます。社内文書や過去記録を検索して根拠つき候補を示し、人が確認と復旧判断を担うためです。まず社内FAQや過去の問い合わせ記録を整理し、Teamsで候補提示を試験運用します。
読む
AIエージェントの提案を人が承認し、月100時間を取り戻す業務改革
AIエージェントの提案を人が承認することで、月100時間近い経理作業を取り戻せます。AIが書類を抽出・分類し異常を検知する一方、重要な判断と実行は人が担うためです。まず経費申請に対象を絞り、現状の処理時間や確認漏れを記録して承認フローを設計します。
読む
