0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

あなたの技術ブログを、あなたのAIエージェントが読む

0
Posted at

この記事は2026年7月時点の情報に基づきます。AIエージェントやモデルは短い周期で世代交代するため、個別の製品名や世代に関する記述は前提が変わる可能性があります。

先に結論だけ

技術ブログの読者に、AIエージェントが加わりました。自著記事をエージェントに読み込ませると、ルール作成時に設計意図を短い時間でぶれずに伝えられます。さらに記事は特定モデルの知識やシステムプロンプトの方向づけを含まないため、モデル世代が交代してルールを作り直すときの基準にもなります。

はじめに

私は技術ブログを「将来の自分への投資」だと考えて書いてきました。書いた時点の理解や判断を文章に残しておくと、あとで自分が助かるからです。その「将来の自分」は人間だけではなくなりました。

この記事の想定読者は、技術ブログを書いていて、Claude Codeのようなコーディングエージェント向けにCLAUDE.mdやルールファイルを育てている開発者です。エージェントの導入方法やルールの記法は扱いません。

まず、自分の記事をエージェントに読ませたらルールの骨格ができた体験を紹介します。次に、モデルの世代交代でルールの前提が変わることを踏まえて、ブログ記事が「モデルに依存しない基準」として働くことを説明します。

自分の記事を読ませたら、ルールの骨格ができた

きっかけは、コードコメントとテストの方針を、エージェント向けのルールにまとめようとしたことでした。「コメントにはなにを書き、なにを書かないか」「テストでどこまでを縛るか」を、プロジェクトのルールとして固定するためです。

ルールの文面をいきなり書かせることはしませんでした。まず、エージェントと方針を練るセッションを始めました。その前提として、過去に自分で書いたQiita記事2本1をエージェントに渡しました。コメントやテストについての私の考え方は、もともとこの2本を書いたときに整理したものだったからです。

すると、エージェントはやり取りの内容を記事と突き合わせ、次の3つに仕分けて返してきました。

  • 記事がすでに言語化していた部分
  • 記事にはなく、セッションで新しく生まれた部分
  • 記事の主張とずれていて、ルールで補足した部分

この照合結果は、そのままルールの骨格になりました。セッションを振り返ると、ブログ記事は参考資料以上の働きをしていました。

高密度な文脈注入

過去の思考の蓄積が、記事の読み込み1回でセッションに載ります。同じ設計思想を対話でゼロから語り直すと時間がかかるうえ、話すたびに内容が微妙に変わります。記事は自分の考え方を保存したキャッシュとして働き、意図の再現を安定させます。

整合性のアンカー

エージェントは記事を基準に、「今回のやり取りは過去の自分の立場と矛盾していないか」を検証しました。これが、先ほどの仕分けの3つ目にあたります。過去の立場が文章として固定されているため、矛盾を機械的に突き合わせられます。その場のやり取りだけでは、この検証は成立しません。

既知の基準

セッションのなかで新しく生まれた知見はどれだったのかは、毎回アドリブでプロンプトを作成していると判断できなくなります。記事という既知の基準があると、エージェントは新しい知見を「記事との差分」として切り出せます。基準がなければ、既知の再確認と新規の発見が区別されないまま、最終的にルールに混ざります。

照合に使った自分の記事の1本には、「どのモデル能力を前提にその判断をしたかを、ルール自体に記録しておく」という原則が書かれていました。エージェントはこの原則に従い、「作成するルールに出典としてこの記事を残すべきだ」と自分から提案してきました。記事が、記事自身の使われ方までエージェントに影響を与えた形です。

意図と、その背後にある判断基準を、編集履歴の残る成果物へ落とし込みます。これはソースコードをgitで管理するのと同じ発想です。

モデルの世代交代が、ルールの作り直しを迫る

ルールは一度作れば終わりではなく、常に作り変え続けなければいけません。

世代交代で、ルールの前提が無効になる

Claude 5世代のモデルが登場したとき、Anthropicは新世代向けのcontext engineering(モデルに渡す文脈の設計)の指針2を公開しました。従来のモデル向けに書き込んできた詳細なシステムプロンプトを、大きく削る方針が示されています。

  • システムプロンプトを80%削減しても、測定可能な性能低下はなかったという報告
  • 「自明なことを書くな(Avoid stating the obvious)」という原則
  • CLAUDE.mdの軽量化と、progressive disclosure(必要になった時点で情報を開示する構成)の推奨

つまり、「プロンプトやルールになにを書くべきか」という設計思想は、モデルの世代によって大きく変わります。前の世代に合わせて磨き込んだルールは、次の世代では過剰な指定になり、削るべき対象になります。ルールは、世代交代のたびに作り直しを迫られます。

特定の世代で動くルールは、暗黙知を省く

作り直しの局面で問題になるのが、ルールに書かれていない前提です。

あるモデルのある世代で再現性よく動くルールは、モデルが内部に持っている知識とシステムプロンプトによる方向づけを、当然の前提として省略しています。省略は意図的ではありません。「書かなくても動く」ことを確認しながらルールを磨くうちに、動作に必要な知識のうちモデル側が負担している部分が、書き手からも見えなくなります。

世代が交代してこの前提が入れ替わると、ルールは静かに壊れます。壊れたルールだけを手がかりに作り直すと、消えた前提を推測で埋めることになります。

人間向けに書いた記事は、モデルに依存しない基準になる

ここでブログ記事に戻ります。

ブログ記事は人間の読者を想定して書かれています。読者が、書き手の使っているモデルと同じ知識を持っているとは期待できません。前提・理由・判断基準を、自然言語で自己完結的に説明するしかありません。この「人間向けに書いた」という制約が、結果としてモデル由来の暗黙知を記事から締め出します。

そのため、モデルの世代が交代しても記事の意味は保たれます。新しい世代のエージェントにルールを作り直させるとき、旧世代向けのルールではなく、自著記事を基準として渡せます。ルールは特定世代向けに圧縮された派生物であり、記事は圧縮前の設計意図の記録である、という役割分担です。

おわりに

技術ブログという「将来の自分への投資」のリターンを受け取る側に、あなたのAIエージェントが加わりました。エージェントは記事を読み、過去のあなたの立場との整合性を検証します。そのうえで、設計意図を新しいルールへ変換します。

しかもこの読者は、モデルの世代が変わるたびに記事を読み直します。次にエージェント向けのルールを書くときは、まず自著記事を読ませてみてください。

  1. テストやルールになにを書くかは、なにをエージェントに任せるかで変わる。エージェントが最適化を担うとき、ソースコードは動作の完全な定義ではなく要求仕様として扱える。 ↩

  2. The new rules of context engineering for Claude 5 generation models | Claude by Anthropic。2026年7月27日閲覧。 ↩

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?