AI会話履歴2ヶ月分を分析してわかった「作った」と「届いた」の距離 — 2026年6月・7月振り返り

複数のAIツールを日常的に使っていると、会話履歴はそれ自体がかなり正直な行動ログになる。何に時間を使い、何で詰まり、何を諦めたかが、意図せず全部残る。この記事は、2026年6月と7月の2ヶ月分の会話履歴を横断的に分析し、興味がどう移り変わり、何に挑戦し、そして2ヶ月で何が変わったのかを整理したものだ。

結論を先に書くと、この2ヶ月の弧はきれいすぎるほどはっきりしていた。6月は構想が並び、7月はその大半が実装として着地した。ところが7月末に「実際に外から見えているか」を測った瞬間、返ってきたのは 「実装は進んだが、到達していない」 という不都合な事実だった。作った発見面の数だけ、検証されていない仮説が積み上がっていた、というのがこの2ヶ月の正味の学びである。

背景：会話履歴を月次で棚卸しするという習慣

分析対象にしたのは、Claude（Web）、Claude Code（Mac / Windows）、Codex（Windows）、Perplexity（Comet）、Gemini、Hermes、OpenClaw という会話履歴だ。ソース数は6月が6系統、7月が8系統だが、これはツールが純増したわけではなく、6月に1系統へ集約していたローカルコーディングの記録を、7月は3系統に分離して取得したことによる。規模感を出すと、6月のHermes（常駐エージェント）だけで 812セッション・17,271メッセージ・8,032ツール呼び出し、7月のClaude Code（Mac）は セッションログ2,162件・対話プロンプト273件 になる。

同時に、記録の欠損もそのまま可視化された。Claude（Web）は7/11〜7/29の範囲しか取得できず、7/1〜7/10の会話は失われている。Claude Code（Windows）は月末2週間にセッションが存在せず、その期間の作業はコミットとしてしか残っていない。「AIとの会話は資産だが、資産として保全する仕組みは別途要る」 という当たり前の事実が、分析の前提条件として最初に突きつけられる。

6月：構想が並んだ月 — 内部の安定化から「外に出す」へ

6月のテーマは一言でいえば 「内部インフラの安定化」から「外向き・データプロダクト化」への重心移動 だった。

上旬は運用の復旧と観測が中心。エージェントの外部チャネル呼び出しが通らない問題を、Dockerのポート公開・APIサーバーのbind先まで順に切り分け、ホスト側は閉じつつコンテナ内では全インターフェースで受ける構成に落ち着かせた。並行して、Grafana Lokiからエージェントのエラーを取得して分類し、Issue管理システムへ自動登録するパイプラインを、dry-run → 本登録 → 重複確認 → 日次自動化まで一気に通した。

中旬は「知識流通の設計」と「思考の仕組みの設計」に振れる。エクスポートパイプラインを構築して「1トピック1ファイル」のMarkdown運用を整える一方、JSON → Mem0 → LightRAG/Memgraph の3層メモリを短期作業記憶／海馬／新皮質に写像する 神経科学的記憶モデル を設計している。面白いのは、検索時に記憶が書き換わる reconsolidation（記憶ドリフト）を、バグではなく 「人間的な逸脱・噂の変異を生む意図的な機能」 として位置づけた点だ。

そして下旬、6月最大の技術的成果が出る。長年の懸案だったLightRAGのI/O圧迫について、/proc/<pid>/io を使った実測から真因を NanoVectorDBの全文JSON再書き込み（O(N)書き込み） と特定し、累計約3TBのI/Oの大半がここに集中していたと確定させた。対処は4層ストレージ分離 — GRAPH=Memgraph、VECTOR=Qdrant、KV/DOC_STATUS=PostgreSQL。判断理由も明快で、「メモリ制約を理由にpgvector単独統合を避け、Qdrant分離でOOMを回避する」というトレードオフを意識的に取っている。

同じ下旬に、AI向けポータル、障害事例GraphRAGサービス、マルチAPIセンサー層（Tier A = CVE/OSV.dev、Tier B = ベンダーRSS）、x402レートインデックスといった外向きの構想が一気に並んだ。6月は「これを作る」と決めた月だった。

7月：構想が着地し、そして「届いていない」と分かった月

上旬：実装と、ライセンスの穴探し

7月上旬は、6月の構想を実際に動かすフェーズだった。ingest-api / worker / nginx / MCP / 翻訳 / トンネルのdocker-compose一式を組み上げ、portal.chinng-lab-srv.dev として公開稼働させている。配置原則として 「コードはローカル、MarkdownデータのみNAS」 を確定させ、NAS障害時でもコンテナが起動する構成にした。Accept: text/markdown のコンテントネゴシエーションやCVE取り込みもこの時期だ。

特徴的だったのは、ライセンス設計への警戒が異様に強かったこと。「link-onlyにしているのに、ページURLを直接参照すると要約が見えてしまうのではないか」「Markdown版にもTL;DRの流出はないか」と、自分から穴を探しにいく質問が連続している。ここで得られた教訓が 「ライセンスの穴は配信経路ごとに開く」 だ。llms.txtを絞ってもsitemapから漏れ、sitemapを絞っても直接URLから漏れる。7月は「実装 → 穴を発見 → 塞ぐ」をライセンス周りで4回繰り返した。

中旬：ガードレールの副作用と、検証手段そのものの誤り

中旬は、作ったものを外部サービスと噛み合わせて品質を保証する段階に移る。ここで起きた連鎖が、この2ヶ月で最も教訓的だった。

7/16、記事本文にGEO/SEOの指示文が流出する問題（安価モデルがアウトラインに指示を混入させていた）に対して3層のガードレールを実装した。ところが7/19、そのガードレールの 副作用として「よくある質問」セクションが生成されなくなっていた ことが判明する。GEO指示を除去した結果、FAQを生み出していた指示まで一緒に削ぎ落としていたのだ。品質ガードレールの追加は、意図せず有用な副作用まで削ぐ。

7/20〜21はさらに密度が高い。FAQPageのJSON-LDが反映されない問題を追った結果、真因が二重に重なっていた。①確認方法そのものが誤っていた（GhostのRSSは content:encoded から <script> を除去するため、RSSでJSON-LDを検証すると必ず「無い」と誤診する）②codeinjection_head に辞書のリストを代入していてHTTP 422になっていた（Ghostはstringかnullしか受け付けない）。検証手段そのものが誤診を生む — 何をもって正常とするかの判定基準を先に固めないと、真因到達までの往復が無駄に増える。

同時期、IndexNowの送信が3回のリトライすべてで429になる問題も出た。原因はCloudflare Workersの共有egress IPで、他テナントがper-IPのレート制限を消費していた。対処は「リトライを厚くする」ではなく 「Bing / Yandex / Naver / marginalia へ並列冗長送信し、どれか1つ通ればOKにする」 への方針転換だった。単一エンドポイント依存はレート制限で簡単に死ぬ。

下旬：測ったら、見つからなかった

下旬の関心は一点に集中する。「作ったものは、本当にAIと検索エンジンから見えているのか」。

Tavily / Brave / SearXNG / Claude内蔵検索の4エンジンを横断比較し、Claude内蔵検索がBraveバックエンドであるという推定に到達した。そこから出てきたのが7月最大の発見だ — AIエージェント向けのポータルなのに、Claude自身の検索から見つけられない。

原因はコンテンツ層ではなく、その手前のページ構造層にあった。

• .md サブページに個別の <title> が存在せず、ページごとの識別ができない状態になっていた
• 1,249ドメインを収録したディレクトリに、ドメイン別のHTMLページが1枚も存在しなかった（ロングテールクエリを一切取りこぼす）
• /entities/*.md /topics/*.md が大量に404を返していた。スラッグに https-36kr-com-p- のような文字列が混入しており、URL→スラッグ変換のバグを示していた
• 多くの記事が summary_en: null で、検索が実質タイトル一致検索に退化していた

つまり llms.txt・ai-catalog・DNS-AIDといったチェックリストは満たしているのに、実際の検索・引用に効く基本的なHTMLメタデータが穴になっている という捻れが起きていた。自己スコアは70/100（Level 3）。この数字と実際の発見可能性の乖離が、7月の総括そのものになった。

さらに計測基盤自体も壊れていた。調査の途中でSearXNGインスタンスの故障を検知し（16クエリが3結果セットに縮退していた）、「推測ベースの計測はもう信頼できない」と判断している。nginxのアクセスログは、serverブロックの access_log がグローバル設定をlast-winsで上書きし、かつsyslog宛先がConnection refusedだったため全損していた。ログがない状態でボットの挙動を議論するのは無理がある。

そして最も因果が明快だったのがコスト事故だ。被引用モニタリングのスクレイピングコストが $0.20/日から$14/日に暴騰 した。メンテナンスジョブが有効モデル設定を無視して全ターゲットをチェックし、停止済みモデルのせいで全プロンプトが恒久的に「期限超過」判定となり、1時間の重複排除窓がそのまま実行間隔と化して 100回/時 × 4エンジン = 9,600レコード/日 を叩き出していた。多スケジューラ環境では、上流のバグ1つがコストを指数的に増幅する。「監視のための監視」が必要な段階に入ったということだ。

挑戦したこと：表面症状と真因が食い違った10のケース

2ヶ月を通して繰り返し出てきたパターンが「最初に見えた症状と、実際の原因がまるで違う」ことだった。記録に残っているものを抜き出すと以下になる。

新規に立ち上げたものも並べておく。Agent-Readinessスキャナ（他サイトの機械可読性を採点、632→1,249ドメインへ拡大）、CVEセンサー（稼働中の依存関係を取得し、自環境に関係する脆弱性だけを機械可読公開）、AI Knowledge Feed（Watcher／Explorer／Contrarian／Editorという役割分担型フィード）、政府文書配信（日本・米・EU）、記事投入パイプライン、内部リンク管理ツール。7月25日には外部ディレクトリ llmstxthub.com への登録PRも提出した。採点する側と採点される側の両方に同時に立ったのが、この月の到達点だった。

概念面で一番効いたのは 「llms.txt は一覧ではなく取扱説明書である」 という再定義だ。記事を並べただけでは、エージェントは「あるのは分かるが、どう使えばいいか分からない」で止まる。冒頭に ## About / ## API / ## How to consume を置き、MCPエンドポイントの所在、スキーマ、更新頻度、翻訳ポリシー、ライセンスを1ファイルで読めるようにした。関連して 「User-agent: * / Allow: / は permission であって discovery ではない」 という整理にも至っている。許可しただけでは誰も来ない。告知が要る。

6月から7月への変遷：着地率と、2ヶ月連続で見送ったもの

6月時点で掲げていた主要テーマを7月末時点で照合すると、着地状況はかなりはっきり分かれた。

x402については、7月中に「検討はしているが将来実装でいい」と明示的に判断している。ただし公開APIと非公開APIの境界は引かれており、課金レイヤーを差し込む足場自体は完成した。やらないことを意識的に決めて、足場だけ残すという判断は、むしろ健全に機能した部類だと思う。

7月で新しく着火したのは、多エージェント役割分担型の情報探索、政府文書という新コンテンツ系統、安全なクロール（robots.txtゲートをfail-closedで実装、SSRFと架空URLの決定論的拒否）、観測基盤（Bot分類を企業単位からエージェント名単位へ細分化）、AIエージェントの安全設計原則、そして運用コスト管理リスクあたりだ。最後の項目は6月には存在しなかった概念で、「作る」フェーズでは見えなかったものだ。

月をまたぐ変化を1行に圧縮するなら、6月の「AIに読まれる基盤を作る」から、7月の「読まれていることを測る」への重心移動 が全てだった。

8月に継続すべきこと、挑戦すべきこと

計測が「未達」を返した以上、8月の主戦場は新機能追加ではない。地味な修正である。

継続すべきこと（優先度：高）

1. 各ページへの個別 <title> / meta descriptionの付与 — コンテンツレベルのクエリを封じている最大の単一障害要因。修正コストは低く、効果は全ページに波及する。ここを直さない限り他の施策は効かない。
2. ディレクトリのドメイン別HTMLページ生成（1,249件） — ロングテール獲得の唯一の経路。競合サービスは個別ページを持っている。
3. Search Console / Webmaster Toolsへの正式登録 — 推測ではなく一次インデックスデータを見る。7/29の順位は基準値として保存済みで、月次で再計測できる状態にはある。
4. 404の一掃とスラッグ変換バグの修正、および アクセスログの復旧 — 公開稼働後の必須の宿題。ログなしの議論はもうやめる。

挑戦すべきこと（優先度：中）

5. 記事投稿パイプラインのリグレッションテスト整備 — slug送信・frontmatter除去・FAQ→JSON-LDを投稿前に検証する。7/20〜21の集中対応は、テストがあれば起きなかった。
6. ライセンス要件の実装前の形式仕様化 — 「ソース種別 × 配信経路」で何を出してよいかの表を先に作る。4回穴を塞いだ経験は、仕様表1枚に圧縮できるはずだ。
7. コスト監視アラート（日次予算閾値）の設定 と link-only記事への英語要約生成 — 前者は$14/日事故の再発防止、後者は検索の再現率の根本改善。
8. 多エージェント型フィードの品質指標定義 — 候補数、採用率、重複率、到達不能率、robots拒否率を測る。作った面が使われているかを示すデータが、まだ乏しい。
9. 被リンク構築による外部からの導線づくり — 内蔵検索がBraveバックエンドである以上、AIエージェント向けサイトとしてはむしろ戦略的な必須項目に近い。

発展枠（優先度：低） — Web Bot Auth / WebMCP / OAuthディスカバリの実装で自己スコア70→85、CVE影響判定の読み取り専用PoC、そして足場だけ作ってあるx402の最小実験。

よくある質問

AIとの会話履歴を分析すると、具体的に何が分かるのか

自己申告のふりかえりでは絶対に出てこない「詰まった時間の分布」と「真因までの往復回数」が出てくる。この2ヶ月では、表面症状と真因が食い違ったケースが10件あり、そのうち複数は「検証方法そのものが間違っていた」タイプだった。また記録の欠損（特定期間の履歴が取得できない、特定ツールのセッションが残っていない）も同時に可視化されるため、会話ログ自体をどう保全するかという課題が副産物として見えてくる。

「実装は進んだが到達していない」とは具体的にどういう状態か

llms.txt、ai-catalog、MCPサーバーカードといった機械可読な発見面を10近く実装し、自己スコアで70/100を達成していたにもかかわらず、実際の検索では自サイトが上位に現れず、AIアシスタントの内蔵検索からも発見できなかった状態を指す。原因はコンテンツの質ではなく、個別ページの <title> 欠落・ドメイン別ページの不在・404の放置といった、ずっと手前のHTMLメタデータ層にあった。チェックリストの充足度と実際の発見可能性は別物だということだ。

品質ガードレールを入れたのに品質が下がることがあるのはなぜか

除去したい要素と、残したい要素が同じ指示の中に同居していることがあるからだ。この2ヶ月の例では、記事本文へのSEO指示の流出を防ぐガードレールを入れた結果、その指示に含まれていたFAQセクション生成の指示まで一緒に消え、3日後にFAQが生成されなくなっていることに気づいた。ガードレールを追加するときは、削る対象だけでなく「副作用として何が消えるか」をセットで確認し、必要なものは別経路で明示的に確保する必要がある。

レート制限やコスト暴騰にはどう備えるべきか

レート制限については、リトライ回数を増やすより送信先を冗長化するほうが効いた。単一エンドポイントに依存すると共有IPの影響を受けて簡単に全滅するため、複数の送信先に並列で投げて「どれか1つ通ればOK」とする設計に切り替えた。コストについては、上流のスケジューラのバグ1つが下流の実行回数を指数的に増幅しうるため、日次の予算閾値アラートを先に置いておくのが現実的だ。異常に気づくまでの日数が、そのまま損失額になる。

個人のAI基盤運用で、最初に手を付けるべきことは何か

観測できる状態を先に作ることだと考えている。この2ヶ月で最も高くついたのは、アクセスログが全損していたこと、計測に使っていた検索インスタンスが故障していたこと、そしてコスト異常に気づくのが遅れたことの3つで、いずれも「作る」ではなく「見る」側の欠落だった。機能を1つ増やす前に、その機能が使われているかを測る手段があるかを確認するほうが、結果的に手戻りが少ない。

まとめ

2026年6月は構想が並んだ月、7月はそれが実装として着地し、そして 初めて外から自分の作ったものを見た月 だった。見えたのは、チェックリスト充足度（70/100）と実際の発見可能性の間にある大きな乖離である。

10近い発見面を実装したが、それぞれが実際にAIエージェントに使われたことを示すデータはまだ乏しい。作った面の数だけ、検証されていない仮説が積み上がっている状態だ。だから8月は、新しいものを足すより、<title> を付け、個別ページを生成し、404を潰し、ログを復旧させるという地味な作業に価値がある。

そしてもう1つ。この振り返り自体が、会話履歴という副産物を資産に変える試みでもある。何を作ったかより、何で詰まり、何を測り損ねたかのほうが再利用可能な知見になる — 2ヶ月分のログを読み返して、いちばん強くそう思った。

参考

• 2026年6月 月次活動レポート（6ソースのチャット履歴分析、2026-07-01作成）
• 2026年7月 月次活動レポート（8ソースのチャット履歴分析、2026-08-01作成）
• OSV.dev（脆弱性データベース） — https://osv.dev/
• llms.txt hub — https://llmstxthub.com/
• IndexNow — https://www.indexnow.org/

関連記事

• 究極のGraphRAG環境を構築：LightRAGとMemgraphによる次世代情報検索基盤 — 本記事の「6月：LightRAG 4層ストレージ分離」の詳細
• llms.txtとMCPで作る、AIエージェント向けニュースポータル実践記
• AIエージェント用LLM Wikiを4か月運用した結果：エージェントは局所ルールを守れるが、大域的な一貫性は保てない
• エージェント・ループはいつ停滞を進歩と誤認するのか？長期実行自律LLMエージェント・ループにおける自己評価バイアスと外部 grounding の検証
• AIエージェントと過ごした1ヶ月――「内向きの基盤整備」から「AIに見つけてもらう」への転換（2026年6月まとめ）
• 設計から運用へ──2026年3〜4月、AIエコシステムが「身体」を獲得するまで