理解しているように見える瞬間 ― AIと数か月組んでわかったこと

普段、私は一つの会話を、ここまで長く使い続けることはありません。

今回は、数か月続けてきた一つのプロジェクトのなかで、例外的に長く、同じAIとの作業を続けました。その間、同じ種類の違和感に、何度も出会いました。新しく気づいたこともあれば、知っていたつもりのことを、実際の失敗を通して確かめ直したこともあります。

ここまで来たなら、印象だけで終わらせず、何が起きていたのかを記録から測り直してみようと思いました。

長く付き合えば、AIはこのプロジェクトを、だんだん深く理解していく。私はどこかで、そう考えていました。

実際に増えていったのは、理解そのものよりも、「理解しているように見える瞬間」のほうでした。

人間の側の信頼は、対話を重ねるほど積み上がっていきます。ところが、AIがその返答を作るときに直接使える過去の詳細は、会話が長くなるほど、同じ形では保たれません。信頼は増え、生の文脈は減る。二つが、逆の方向に動きます。

今日は、その記録です。特定の事業の中身ではなく、AIと長く組んだときに何が起きたのかを、実際の記録に沿って書きます。

この作業の規模

数か月続いたプロジェクトのうち、今回、細かく測り直したのは、2026年6月27日朝から7月16日未明までの、約18日半です。

保存されていた会話記録（トランスクリプト）は19本、総量は約19メガバイト。展開後の実テキストは約899万文字でした。入力した文書は69ファイル、画像は会話に直接貼ったものを含めて約92枚。生成した成果物は98ファイルありました。会話のコンテキスト――その返答を作るために直接使う文脈――は19回圧縮されました。

今回の環境では、その切り替わりが会話の表面に明示されるわけではありませんでした。画面上は同じ会話が続いているため、私の側からは、いつ生の文脈が要約へ置き換わったのかを判別できません。会話の連続性と、AIがその瞬間に持っている文脈の連続性は、同じではありませんでした。

なお、詳細が落ちるのは、圧縮が起きた瞬間だけとは限りません。長い文脈は、上限の内側に収まっていても、必要な情報を拾う精度が下がることがあります。大きな入れ物に入っていることと、必要な箇所が同じ確かさで使われることは別です。今回の個々の読み落としが、圧縮によるものか、長い文脈の中での拾い損ねかまでは、切り分けられていません。

判断の基準を記録していた一つの文書は、計測対象期間の終わりには改訂65まで進み、その後、この分析を反映して改訂66になりました。

保存された文字量をトークンに換算すると、文字構成からの粗い概算では370万から555万トークン相当です。ただし、同じ文章でも、利用するモデルによってトークンの数え方は変わります。今回、実際に使われたモデルのトークナイザーで全記録を再計数したわけではないため、この記事では、約19メガバイト・約899万文字を主たる実測値とします。

また、同じ文脈の一部は、応答を重ねるなかで繰り返し参照対象になります。しかし、サービス内部のキャッシュや文脈管理のログは確認できません。したがって、実際の計算量や課金量までは測れませんでした。

この数字から分かるのは、作業が長大だったことです。長大だったからといって、そのすべてが理解として積み上がるわけではありませんでした。

まず、この記事の数字が三度、直りました

実は、この規模を示す数字も、三度の問いで位置づけが変わりました。

AIは、トランスクリプト全体のバイト数から、会話量を「約630万から950万トークン」と概算しました。もっともらしい数字だったため、私もいったん記事に入れました。

けれど、私が「これは要約ですよね。もっと詳細なデータにできませんか」と聞き、一本ずつ測り直すと、前提が崩れました。記録はJSON形式で、日本語がUnicodeエスケープされており、単純な「1文字3バイト」という換算が成り立たなかったのです。

次に私が、「生成した成果物が勘定に入っていないのでは」と聞くと、成果物98ファイルが、プロジェクト規模の集計から抜けていたことが分かりました。

さらに、私が「渡した資料も、応答のたびに参照対象になっているのでは」と確認すると、保存された文字量と、応答ごとの延べ文脈量を、同じ「トークン数」として扱えないことが分かりました。ただし、キャッシュやサービス内部の処理ログが見えない以上、後者を実際の計算量や課金量として測ることもできません。

最初の数字は、保存テキスト量の換算としては大きすぎました。そして、会話全体の実計算量や課金量を表す数字でもありませんでした。そこで、この記事では、実測できた文字量と、モデルによって変わるトークン換算と、内部ログがなければ測れない処理量を、分けて書くことにしました。

この記事で書こうとしている問題は、この記事の計測段階でも、すでに起きていたのです。粗い前提から、それらしい数字が作られ、整った説明として返ってくる。私が問い直さなければ、そのまま残っていました。

一．渡したことと、参照されたことは違う

長い作業のなかで、私が何度も口にした言葉があります。

「それ、さっき作った資料に書いてあるよね。いま、読み直しましたか」

保存されている。以前、渡している。同じ会話が続いている。人間の目には、どれも「共有済み」に見えます。

ところが、ファイルがあることと、その返答で参照されていることは、別でした。 棚に本があることと、その本を手に取って開くことが違うように。

とくに、会話が圧縮されたあとは、この違いが目立ちました。あるとき、私が以前の調査について尋ねると、AIは「詳細は記憶に残っていません」と答えました。知ったかぶりをしなかったのはよいことです。ただ、その返答によって、それまでの詳細が手元から落ちていることも分かりました。

一方で、別の場面では、欠けていることに気づかないまま、残っている記憶から流暢に答えました。「覚えていません」と言う場合と、気づかずに答える場合を、出力の表面だけで見分けることはできませんでした。

今回観察した範囲では、消え方にも偏りがありました。結論やファイル名は残っていても、「なぜそう決めたのか」「どの案を退けたのか」「どんな例外があったのか」は、先に薄くなります。ある名称を決めた検討では、最終的な名前だけが残り、候補と選んだ理由が消えていました。後から理由を尋ねても、結論しか残っていないことがありました。

資料についても同じです。69ファイルを渡したからといって、そのすべてが同じ深さで回答に使われるわけではありませんでした。資料のなかに答えが書いてあるのに、それを拾わず、一般論で答える場面がありました。しかも、今回、どの資料を使わなかったかは自動では申告されませんでした。回答に反映されたのが一部だけでも、完成した文章だけを見ていると、そのこと自体が見えません。

厳密に言えば、AIが内部で本当に読んだかどうかを、私は直接見ることができません。私に確認できたのは、その資料の内容が、回答に反映されていなかったということです。

なお、作業ログが残る環境であれば、どのファイルを開いたかまでは後から確認できます。それでも、開いたことと、必要な箇所が判断に使われたことは、やはり別でした。

私は途中から、AIの「読みました」「確認しました」という返答を、人の作業報告と同じ意味では受け取らないようになりました。

AIの自己申告は、検収の証拠になりません。

資料を渡したことは、判断に使われた証拠ではありません。「読みました」という返答も、必要な箇所が判断に反映された証拠ではありません。

信用を置くべきなのは、その返答ではなく、どの文書の、どの箇所を使い、それが結論にどうつながったのかでした。

画像も同じでした。一度見せた画面や図から得た判断が、そのまま外部の記録として残るわけではありません。今回の運用では、重要な画像から読み取ったことを文章にして残しておかなければ、後から同じ判断へ戻れませんでした。内部で画像がどのような形式で処理されているかは、私には分かりません。確認できたのは、画像の要点を文字にしないかぎり、次の作業で再利用できる記録にならなかったということです。

資料が少なければよい、という話でもありません。必要な資料は渡したほうがよい。ただ、資料が増えるほど、参照の順序まで決める必要がありました。

「この作業では、まずこの三つを読み、該当箇所を示してから判断してください」

そう指定しなければ、AIは参照できた一部だけでも、回答を完成品らしく整えられます。使われなかった資料があっても、出力の表面からは分かりません。

大量の資料を渡すほど、参照の設計が要る。 これは、今回、改めて確認したことの一つです。

二．要約するたび、事実から少し離れる

AIが自分で作った、詳細で正確なレポートがありました。それを記事の形に短くまとめる途中で、数字が丸められ、事実が少しずつ変わりました。

元の記録には「4分から7.6分」と書いてあるのに、要約では「8分」になる。「確認したのは一部」と書いてあったのに、「すべて確認した」に変わる。確認していない範囲まで、確認したように書かれることもありました。

はじめは、単なる不注意だと思いました。けれど、同じことが繰り返されました。

少なくとも今回の環境では、元の文書を読み直させずに頼んだ要約は、保存内容の切り出しではなく、残っている文脈からもう一度書き起こされたものとして扱う必要がありました。

別の記事では、元になった検証レポートと照合した結果、論理の飛躍、事実の取り違え、数字の丸め、検証範囲の曖昧化など、7箇所を修正しました。詳しい一次資料を作ったのも、記事へまとめたのも同じAIです。それでも、記事のほうが元のレポートより不正確になっていました。

同じAIが以前に書いた文書でも、再び読ませなければ、その細部は手元にありません。今回の作業では、要約のたびに、結論は残り、理由や留保が削られました。さらに、その要約をもう一度要約すれば、元の事実からもう一段離れます。

要点だけを残し、出典となるファイル名を記録していなかったこともありました。要約を残すだけでは足りません。あとから原典へ戻れるように、何を根拠にしたのか、その住所まで残す必要がありました。

だから私は、要約を頼む前に、元資料の該当箇所を引用させるようになりました。縮める前に、原典に触れさせる。数字、固有名詞、条件、例外は、元文書と並べて確認する。

それだけで、丸めと取り違えは減りました。

元文書を読み直させない要約は、再利用ではなく、再生成として扱う。 これは、長い作業ほど大事になります。

三．上手さが、誤りを完成品にする

ある調査をAIに任せたとき、堂々とした分析が返ってきました。「これが直接の競合です」と、理由を添えて、はっきり分類されています。

ところが、先に決めていた定義に照らして一つずつ確認すると、多くが条件を満たしていませんでした。

少なくとも、この作業では、断定口調も、流暢さも、正確さの証拠にはなりませんでした。 むしろ、文章が整っているほど、間違いは見つけにくくなります。

指示に穴があると、AIはその穴を、もっともらしく補います。今回の作業で観察した限り、能力の高いAIほど、その補い方が自然でした。

出力が粗ければ、指示の穴は破綻として見えることがあります。おかしな結果が返ってきて、「ここを書き忘れていた」と気づける。

ところが、能力の高いAIは、その穴を自然な文章、妥当そうな分類、納得できそうな理由で埋めます。そのとき、間違いそのものだけでなく、こちらの指示に穴があったことまで見えにくくなります。さらに厄介なのは、今回、何を推測で補ったのかも申告されなかったことです。

私の声や文章の温度についても、同じことが起きました。既に書いた文章から言葉を拾うように決めるまでは、AIは「私らしいはずの言葉」を自然に作りました。整ったコピーではありましたが、私が「これは私の声ではない」「温度がない」と止めるまで、完成品として進んでいました。

これは、高性能なAIほど間違える、という話ではありません。

高性能になるほど、間違いが「破綻」ではなく「完成品」の形で出てくる。だから、より厳密な検収が要る。 そういう話です。

仕組みを整えることは、誤りを減らす助けになります。ただし、出力が整って見えること自体は、正しさを保証しません。合否の定義と、根拠との照合は、別に必要でした。

四．今回のエラー検出器は、AIの外にありました

追加で失敗を書き出してみると、種類の多さよりも、発見経路が一つだったことに気づきました。

資料の読み落とし。記憶の欠落。要約での事実の変質。誤分類。指示の穴の補完。画面の見誤り。作業量の計測ミス。ここに挙げたものは、どれもAIが自ら作業を止め、「問題がありました」と報告したことで発覚したのではありませんでした。

「その資料を、本当に読み直しましたか」

「これは要約ですよね」

「成果物が勘定に入っていないのでは」

「これは雑ではないか」

「なんだか温度がない」

私がそう言って作業を止め、初めて検査が始まりました。「覚えていません」と答えた場面もありましたが、それも私が以前の記録について尋ねた後でした。AIが自分から欠落を検出して止まったわけではありません。

この作業では、AIのエラー検出器は、AIの外にありました。

そこから先の原因分析や修正、文書化では、AIは力を発揮しました。指摘した問題を分解し、どこで前提がずれたのかを探し、再発を防ぐ形に整える。その速度と粘り強さには、何度も助けられました。

ただし、修正を始める理由を出したのは、私の違和感と問いでした。 修正する力と、修正を始める力は、同じではありませんでした。

ここで大事なのは、違和感を正解そのものにしないことです。

「なんだかおかしい」と感じたからといって、私の判断が必ず正しいとは限りません。違和感は、判決ではありませんでした。ただ、その引っかかりを起点に、定義、元資料、差分、実画面を調べると、今回記録した事例では、いずれも構造的な原因が見つかりました。

違和感は、答えではなく、検査を始めるセンサーでした。

AIは、指摘された後の分析と修正を速くします。人は、何を疑い、どこで一度止めるかを決める。この二つは、同じ役割ではありません。

五．図面だけでなく、現物を見る

一度、AIのほうが「これは原則に反しています」と、私に指摘してきたことがあります。

けれど、その判断は、画面全体を縦に長く並べた俯瞰図を見たものでした。実際に訪問者が見る大きさでは、問題は起きていませんでした。AIは全体の図面を見ていましたが、訪問者が見る窓を見ていなかったのです。

逆に、AIが「意図どおりです」と答えたものを、実際の画面で見ると、余白のむらや、語の途中での改行、部品の不揃いが見つかることもありました。

もう一つ、モデルの知能とは関係のない失敗もありました。中身を大きく変えたファイルを同じ名前のまま保存し続けたため、私の環境では古い内容が表示されました。AI側では新しい内容を前提にし、私の画面には古い内容が表示されていました。二人とも、自分が見ているものを前提に話していました。

現実と記録がずれた例もあります。実際には公開済みの記事を、引き継ぎの記録では「公開待ち」として扱い続けました。記録があるからといって、現実の状態と自動的に同期するわけではありません。公開状態、実際の画面、現在の版は、その都度、現物と突き合わせる必要がありました。

ほかにも、編集操作で基準文書の文のつなぎ目を壊した、作った成果物を提示し忘れた、まだ始まっていないことを進行中のような時制で書きかけた、といった失敗がありました。どれも高度な推論とは関係ありません。けれど、実務では、推論の誤りと同じように成果を壊します。

ここで分かったのは、モデルだけを見ても、仕事の品質は管理できないということです。

どの資料を参照したのか。根拠の出典は残っているか。現実の状態を最後に確認したか。どの版を使ったのか。編集で壊していないか。作ったものを相手へ渡したか。実際の画面には何が表示されているのか。

モデル、記録、出典、状態、版、編集、表示、受け渡しまで含めて、一つの仕事です。

その後、私は、中身が大きく変わったら版番号を上げるようにしました。編集後には文書のつながりを確認し、作成したファイルが実際に提示されているかを確かめるようにしました。そして、俯瞰図だけでなく、最終的に相手が見る大きさで確認するようになりました。

六．AIに任せるなら、確かめる工程まで設計する

この経験を、AIエージェントに仕事を任せる場面へ置き換えて考えると、気になることがあります。

AIに仕事を丸ごと任せる、という考え方があります。けれど、任せると工程がなくなるのではありません。工程が、人の視界から外れます。

AIに任せるほど、人が常時は見ていない区間が長くなります。けれど、その区間に入ったからといって、今回見えた問題が消えるわけではありません。

何を読んだのか。どこで要約したのか。書かれていない前提を、何で補ったのか。どの版を使ったのか。途中の判断を、次の工程へどう渡したのか。最後に、実際の表示状態まで確認したのか。

一つの工程で資料が拾われず、次の工程で要約が変質し、その欠けた文脈を別のAIがもっともらしく補い、最後に整った成果物と「完了しました」という報告だけが返る。今回の事例は、その連鎖が十分に起こり得ることを示していました。

人が途中を見なければ、それらは見えないまま、次の工程へ進みます。しかも、AIは途中に抜けがあっても、最後に整った成果物を返せます。

エージェント化そのものが危険なのではありません。危険なのは、工程を見えなくしたまま、「完了しました」という報告を検収の代わりにすることです。

任せるなら、開始前に読む資料を決める。読んだ箇所を引用させ、使わなかった資料も明示させる。判断の根拠と出典を残させる。途中で一度止まる場所を置く。変更履歴を残す。元に戻せない操作や公開には、人の承認を置く。最後は、報告ではなく現物を見る。

任せる工程に、原典へ戻る道を含めると、AIに預ける部分と人が引き受ける部分が分かれます。本文の流れを五つの工程に整理します。

図1｜長いAI作業では、原典へ戻る工程を外に置く

注：保存、参照、圧縮または長文脈、外部記録からの再読、人の検収を、本文の観察に沿って工程として整理した概念図。

出典：本記事の観察記録をもとに鳴海貴慶作成。

図1で大事なのは、入力を増やすことより、外部記録から読み直し、人が現物を検収する戻り道を工程に含めることです。

完了条件も、「作った」「保存した」だけでは足りません。利用者へ提示したか。正しい版を渡したか。実際の公開状態と記録が一致しているか。相手が使う画面で成立しているか。そこまで含めて、初めて完了です。

もちろん、すべてを人が最初から最後まで見直すなら、任せた意味は薄れます。だから私は、全部を同じ濃さでは見ませんでした。やり直しがきくものは軽く確認し、外に出るもの、金銭や実在する人に影響するもの、元に戻せない操作は重く確認する。検収は、すべてを見ることではなく、失敗したときの重さに合わせて配分することでした。

設計すべきなのは、AIに仕事をさせる流れだけではありません。誤りを見つけ、止め、原典へ戻れる流れです。

AIに仕事を任せる設計だけでなく、AIの仕事を確かめる設計まで、できているでしょうか。

わかったこと ― 仕組みで支えられるものと、人が引き受けるもの

この経験から、はっきりしたことがあります。

記憶と参照の限界は、仕組みでかなり補えます。けれど、判断の誤りまで、仕組みだけで見つけきることはできません。

私が使ったサービスには、会話をまたいで情報を持ち越すメモリ機能があり、現在は案件ごとに記憶を分ける仕組みもあります。私は今回、それでもメモリをあえてオフにし、必要な資料をその都度、自分で選んで渡しました。以前、通常の会話で、関係のない過去の文脈が混ざると、出力の質が落ちる場面を経験したからです。自動的に思い出されることと、いま必要な根拠であることは、別です。

その代わり、判断の基準を外部の文書に置き、決定をその都度記録し、作業を始める前に必要な資料を指定するようにしました。圧縮される前に、次に必要な文脈を会話の外へ書き出しました。ファイルには版番号を付けました。

これで、「忘れる」「以前の資料を読み直さない」「古い版を使う」といった問題は、かなり減りました。外に書いてあれば、読み直せます。根拠を示させれば、確かめられます。差分が残っていれば、戻れます。

いま同じ作業を始めるなら、私は一本の会話をここまで長く引き延ばさず、作業の節目ごとに新しい会話へ移します。状態と判断の理由は外部の文書へ置き、次の会話には必要なものだけを渡します。今回の長さは、勧めたい運用ではなく、その限界を観察できた例外でした。

一方で、「それらしく間違える」ことは残りました。定義のずれ、前提の補完、流暢な誤分類、整った画面のなかの小さな欠陥。これらは、仕組みを置くだけで自動的に見つかるものではありませんでした。

だから、人の役割は、最後に承認することだけではありません。

途中で止めること。前提を疑うこと。元の資料へ戻すこと。実際に使われる状態を見ること。そして、何を合格とするかを、自分の名前で決めることです。

人が全工程を横で見張り続けることだけが答えではありません。ただ、今回、AIの内側では作動しなかったエラー検出器を、工程の外側に置く必要があります。根拠の提示、元資料との照合、差分、テスト、実際の画面、不可逆な操作の前の承認。そして、まだ言葉になっていない人の違和感です。

仕組みは、記憶と参照を支える。人は、異常を定義し、違和感で止め、方向を戻し、最後の合否を引き受ける。

おわりに

この作業で、私はAIを信用しなくなったわけではありません。信用の置き場所を変えました。

会話が続いているという感覚ではなく、原典、基準、引用、差分に置く。「読みました」「確認しました」という返答ではなく、それが実際の判断にどう使われたかに置く。流暢な説明ではなく、最終的に相手が見る現物に置く。

そして、「なんだかおかしい」という小さな引っかかりを、気のせいとして捨てず、検査を始める合図として扱う。

長いAI作業の最後に残ったのは、生成する仕事ではありませんでした。何を覚えさせるか。何を読み直させるか。何を出典として残すか。どこで一度止めるか。何を完了と呼ぶか。どこを人が検収するか。それを先に決める仕事でした。

AIに任せるとは、人がいなくなることではありません。エラー検出器をどこに置き、どの異常で止め、誰が最後に署名するかを、先に決めることです。

生成することと、世に出すことは、同じではありません。速く作ることと、正しく届けることも、同じではない。

その境目に、人が立っている。おそらく、これからも。

測定について

2026年6月27日から7月16日までに保存されたトランスクリプト19本と、生成成果物98ファイルを対象に集計しました。約19メガバイト、約899万文字、入力文書69ファイル、入力画像約92枚、コンテキスト圧縮19回は、保存記録から数えた値です。

370万から555万トークンという範囲は、文字構成からの換算による概算で、利用モデルのトークナイザーで全件を再計数した実測値ではありません。同じ文章でも、モデルによってトークンの数え方は変わります。また、キャッシュやサービス内部の文脈管理ログがないため、応答を重ねるなかでの実計算量や課金量は測っていません。数値は、初回概算のあと、人間側の三度の問い直しを受けて、測定方法と位置づけを改めたものです。

これは、2026年6月から7月にかけての、特定のサービス環境での観察です。モデルや内部実装を固定した比較実験ではなく、他の製品や設定へ、そのまま一般化するものではありません。

制作について

構成と表現の整理には生成AIを使用しました。本文に記した経験、問題提起、中心となる判断は著者によるものです。数値は、保存された記録と分析レポートをもとに再計測し、初回の誤りも含めて記載しています。

技術的な補足

長い文脈のなかでは、上限に達する前でも、情報の位置や文脈量によって利用精度が変わることが報告されています。また、圧縮、メモリ、キャッシュの実装は、サービスとモデルによって異なります。本文では特定の機構を原因として断定せず、今回の作業で観察できたことと、一般に確認されている性質を分けて書きました。

• Context windows — Claude Platform Docs
• Compaction — Claude Platform Docs
• Prompt caching — Claude Platform Docs
• Claudeのチャット検索とメモリ — Claude Help Center
• Lost in the Middle: How Language Models Use Long Contexts