GenAI週刊 Annex 2026年01月06日号
メインジャーナルからは漏れたものの、独自の価値を持つ記事の特集です。
Annexについて
このAnnexジャーナルは、単なる"残り物"ではなく、ユニークな視点、実験的な試み、批判的思考、そしてニッチな深堀りを提供する厳選された「B面」コレクションです。
今週のB面には、LLMの数理的特性から設計論を再構築する高度な最適化手法、AIの内部表現を解剖する解釈可能性の実践、そして無批判なAI導入への辛辣な警告が集まりました。メインストリームが語らない技術的深度と批判的視座こそが、この特集の真価です。主流に流されず、裏側の構造を見抜く目を養いたいエンジニアのための18本をお届けします。
Advanced Tactics & Unconventional Wisdom
規約ベースのフレームワークはAI処理に不利だと思う
https://nowokay.hatenablog.com/entry/2025/12/28/045145
AI時代においては規約による暗黙的な定義よりもアノテーションなどの明示的な記述の方が、LLMの推論効率とコストの両面で有利である、と主張する。
きしだ氏は、Ruby on Railsに代表される「設定より規約（Convention over Configuration: CoC）」を採用したフレームワークが、生成AI（LLM）によるコード理解や生成において不利に働く可能性を指摘する。挑発的かつ示唆に富んだ論点だ。
主な理由はLLMの「アテンション（注意）」の仕組みにある。CoCでは、クラス名とテーブル名の紐付けなどが暗黙的なルールに基づいているため、LLMがコードを読む際、注目すべき情報が広範囲に分散してしまう。一方、アノテーションベースのフレームワークでは、メタデータがコード内に明示的に記述されているため、LLMは必要な情報の近くに注意を集中でき、処理の精度と効率が向上する。
また、この問題は「経済的な不利」にも直結すると筆者は主張する。規約ベースのコードを正確に扱うには、Claude 3 Opusのような高性能（かつ高コスト）なモデルが必要になるが、明示的なコードであれば、より小規模で安価なモデルでも十分に処理できる可能性があるからだ。開発組織がコスト効率を重視してオープンウェイトモデルなどの活用を進める際、フレームワークの設計思想が「AIにとっての扱いやすさ」に与える影響は無視できないものとなる。
具体例として、Railsのモデルクラスを挙げている。Railsではフィールド情報がクラス内に記述されず、マイグレーションファイルなどの別箇所に置かれることが多い。この情報の地理的な乖離が、LLMのアテンションを弱める要因となる。対照的に、アノテーションを用いたJavaなどのアプローチは、その場に情報を「ベタ書き」するのに近く、AIにとってはコンテキストを把握しやすい。
著者は「設定より規約」がかつて解決しようとした問題（大量の設定コードの削減）は、現代のアノテーションベースの仕組みやAIによる支援があれば、もはや大きな課題ではないと示唆する。むしろ、AIがコードを読み書きする現代においては、人間にとっての「記述の短さ」よりも、AIにとっての「情報の明示性」が開発速度を左右する指標になりつつある。AIに「忖度」させるための計算資源を消費するよりも、AIが理解しやすい形式で記述する方が合理的だ——これは、AI駆動開発時代における設計指針の転換を促す、極めて挑戦的な問いかけである。
Claude Code のツール検索ツールを有効にして MCP のトークン使用量を削減する
https://azukiazusa.dev/blog/enable-claude-code-tool-search-to-reduce-mcp-token-usage/
Claude Codeの環境変数を有効化し、MCPツールをオンデマンドで検索・読み込みさせることで、コンテキストウィンドウの圧迫とトークンコストを劇的に削減する。
Claude CodeにおいてModel Context Protocol（MCP）を活用する際、避けて通れないのが「コンテキストの腐敗（Context rot）」の問題である。これは、タスクに不要なツール定義がコンテキストウィンドウを圧迫し、LLMの推論精度を低下させてしまう現象を指す。著者は、PlaywrightやNext.js Devtoolsなど複数のMCPツールを常時読み込むと、それだけで約39,000トークン（コンテキストの約20%）を消費してしまう実例を挙げ、この無駄が開発効率を阻害していると指摘する。
この記事が提示する解決策は、環境変数 `ENABLE_TOOL_SEARCH=true` を用いた「ツール検索ツール」の有効化だ。この機能を有効にすると、Claude Codeは起動時にすべてのツール定義をコンテキストに読み込まなくなる。代わりに、ユーザーの指示に応じて必要なツールを動的に検索・呼び出しする挙動へと変化する。これにより、コンテキストの専有面積を最小限に抑えつつ、膨大な数のMCPツールを実質的に「使い放題」にできる点が大きなメリットである。
技術的な仕組みとして、Claudeは `MCPSearch(...)` という専用ツールを使用する。これには、ツール名を直接指定する「Direct Selection（select:
著者は、LLMが効果的にタスクを遂行するには、コンテキストとして提供する情報を厳選することが不可欠であると強調する。これまでは `/mcp` コマンドで手動の無効化・有効化が必要だったが、この自動検索機能の導入により、エンジニアはMCPツールの管理負荷から解放され、より複雑なエージェントワークフローを低コストかつ高精度に構築できる。ツールを「事前に全て教える」のではなく「必要になったら自分で探させる」というアプローチへの転換は、今後のAIエージェント活用のスタンダードになる可能性を秘めている。
Claude Codeを実務で3ヶ月使って痛感した5つの教訓 #ポエム
https://qiita.com/riiiii/items/b642f039c30d4e9c1bec
AIによる無秩序なコード量産を防ぎ、開発効率を最大化するための実務的な設計指針と人間が担うべき役割の境界線を定義する。
本記事は、Claude Codeを実際のWebアプリケーション開発（約20画面規模）に3ヶ月間投入した著者が、AIエージェントとの協調作業において「実装効率」以上に重要となる運用上の教訓を5つの観点でまとめた実践記である。
著者が第一に強調するのは、AIの「セッション間の忘却」に対する運用上の工夫だ。Claude Codeはセッションが切れると文脈を失うため、ローカルにログディレクトリ（`docs/logs`など）を固定し、`.gitignore`で管理しつつ過去の経緯を即座に再投入できる体制を整えるべきだと主張している。これにより、チーム全体でのコンテキスト共有を容易にし、AIの記憶の断絶を補完できる。
第二に、実装前の詳細設計の密度がAI時代の生産性を左右すると述べている。従来の人間中心の開発では実装中に共通化に気づけたが、AIは独立したタスクとしてコードを生成するため、事前にコンポーネントの再利用ルールやサービス層の責務を厳密に定義しておかないと、不整合なコードが量産されるリスクがある。著者は「AIに渡す設計書のフォーマット能力」が、エンジニアにとっての新たなコアスキルになると指摘する。
第三に、類似機能の「まとめ実装」による一貫性の確保だ。別々のセッションで似た画面を作らせると実装にブレが生じバグの温床となるため、一度の指示で共通化を含めて完結させるか、あるいは「実装計画ファイル」を介してセッションを跨いだコンテキスト同期を行う手法を推奨している。
第四に、設計のシンプルさへの回帰である。AIを使えば複雑なネスト構造も容易に実装可能に思えるが、実際にはデバッグ困難性が増し、動作確認に多大な時間を要する「地獄」に陥りやすい。人間が理解・レビューできる範囲の設計に留めることが、結果としてプロジェクト全体の速度を維持する鍵となる。
最後に、トラブルシューティングにおける人間側の「広範な知識」の重要性だ。AIが特定のレイヤー（フロントエンド等）に固執して解決できない問題も、システム全体を俯瞰できるエンジニアなら数行のバックエンド修正で解決できる場合がある。著者は、AIは「コードを書く時間」は劇的に減らすが「考える時間」は減らさないとし、「設計と判断は人間、実装はAI」という明確な役割分担の徹底を結論とする。
Attention 特性に基づく構造化プロンプト設計
https://qiita.com/qwer123123/items/2f1db6bd52f2e05eb524
TransformerのAttention特性を数理的に解釈し、プロンプトを4つの独立した意味ブロックに構造化することでLLM出力の再現性を向上させる設計手法を提案する。
Transformer型モデルの内部挙動であるAttentionメカニズムに立脚し、LLMから安定した出力を得るための「構造化プロンプト」の設計指針を解説した記事である。筆者は、プロンプト内の情報配置や役割定義が曖昧な場合、Attentionが分散して出力が不安定になると指摘し、これを回避するためにプロンプトを「Role」「Goal」「Constraints」「Output」の4要素に完全分解する手法を提唱している。
筆者によれば、これら4要素は数理的・計算機科学的な意味を持つ。まず「Role」はモデルをどの関数 $f$ として利用するかという「型指定」であり、「Goal」はその関数が最適化すべき「目的関数」の指定にあたる。また、「Constraints」はAttentionの探索空間を制限する「条件集合」として機能し、これがないと探索空間が無限に広がりAttentionが発散してしまうと説明している。最後の「Output」は、最終的なデータ構造、すなわち「出力空間の型定義」である。
本記事がエンジニアにとって極めて実用的である理由は、曖昧になりがちなプロンプトエンジニアリングを、関数定義や集合論といった馴染みのある概念へと抽象化している点にある。筆者は、目的が不十分な入力に対しては、モデルに推測で補完させるのではなく「不足情報を1点だけ質問して停止する」というルールを課すことが、再現性を守るための重要な停止条件になると主張している。
後半では、具体的なユースケースとして「音声文字起こしの後処理」を例に挙げ、上記フレームワークを適用したプロンプト例を提示している。さらに、ユーザーの目的から自動的にこれら4要素を抽出して「最終プロンプト」を生成するメタプロンプトの構成案も示されており、実務での即時導入が可能なレベルにまで落とし込まれている。
AIエージェントにSOLID原則を叩き込んでやろうじゃないか
https://techblog.kayac.com/2025/12/24/100000
AIエージェントに詳細なSOLID原則のガイドラインをコンテキストとして与えることで、生成コードの設計品質と保守性を劇的に向上させる手法を提案する。
カヤックの新卒1年目のエンジニアによる、AIエージェント（Claude Code）の出力品質を劇的に向上させるための実践的なアプローチの紹介である。著者は、AIが仕様通りのコードを出力する一方で、その設計品質を人間がただ漫然とレビューするだけでは、エンジニアとしての自身の成長が停滞し、将来的に淘汰される危機感を感じたと述べている。この課題を解決するため、著者は「SOLID原則」をAIに徹底的に叩き込むことで、AIを単なる作業代行者から、高品位な設計を共創するパートナーへと昇華させる試みを行った。
具体的な手法として、SOLID原則の5つの各要素（単一責任、オープン・クローズド、リスコフの置換、インターフェース分離、依存性逆転）について、厳守すべきルールや「違反を検知する警告サイン」を定義した5つのMarkdownファイルを用意し、Claude Codeのコンテキストとして読み込ませている。例えば、単一責任の原則では「『そして』『また』という説明が必要なクラスは分割対象」といった具体的な判定基準を与え、依存性逆転の原則では「具象クラスを直接インスタンス化しない」といった実装ルールを課している。
このアプローチの有効性は、ラーメン屋の営業をモデル化した実装例で顕著に示された。原則を指定しない場合、AIは全てのロジックを一箇所に集約させた巨大なクラスや、拡張性の乏しい条件分岐の羅列を生成した。対して、原則を叩き込んだ場合、AIはドメイン層やアプリケーション層に分離されたクリーンアーキテクチャに近い階層構造を自律的に構築し、依存性注入（DI）を活用した疎結合なコードを出力した。
著者は、AIに任せきりにすることで発生しがちな技術負債のリスクを、プロンプトやコンテキストの設計によって軽減できると主張する。さらに、AIが生成した高度な設計を人間が読み解くプロセス自体が、ジュニアエンジニアにとっての深い学びになり、設計思想の習得を加速させるという副次的なメリットも強調している。
Substantive Critique & Contrarian Views
Brainf*ck：AGI（汎用人工知能）を測る究極のテスト
https://teodordyakov.github.io/brainfuck-agi/
Brainf*ckを、データの希少性と論理的推論の必要性からLLMの真の知能を測る究極のベンチマークとして定義する。
筆者のTeodor Dyakov氏は、極小の命令セットしか持たない難解プログラミング言語「Brainfck」こそが、大規模言語モデル（LLM）が真の汎用人工知能（AGI）に到達したかを測る究極の試金石であると主張している。現在のLLMはJavaScriptなどの膨大な学習データに依存し、パターンの模倣によってコードを生成しているに過ぎないが、Brainfckはこの「模倣」を無効化するという。
筆者が挙げる第一の理由は「データの希少性」だ。ネット上に存在するBrainf*ckの有効なコード量は、主要言語に比べれば統計的な誤差レベルであり、LLMは模倣に頼ることができない。そのため、モデルは構文を暗記するのではなく、言語の背後にある根本的な論理を理解し、推論する必要がある。
第二に、Brainf*ckが「アンチ・リテレート・プログラミング（非可読プログラミング）」である点だ。コメントや意味のある変数名、構造が一切排除されたこの言語では、既存のコードを参照することさえ学習の助けにならない。成功には、言語の基本ルールに基づいた高度な抽象化と、厳密なセマンティクスのメンタルモデルを自ら構築する能力が不可欠となる。
第三に、LLMの動作原理そのものを突く「繰り返しの問題」がある。Gemini 3などの最新モデルでも、Brainf*ckの生成を命じると特定の文字を無限に繰り返すループに陥ることが多い。これは、最小限の構造が繰り返される言語特性により、LLMの次トークン予測が自己完結的な予言として機能してしまう弱点を示している。
Webエンジニアにとって、この考察はLLMの真の限界を理解する上で重要だ。コピペ可能なコードが枯渇した環境で、モデルがいかに論理的な飛躍を成し遂げられるか。Brainf*ckでのコーディング能力は、LLMが単なる「確率的なオウム」を超え、真の推論能力を備えたAGIへと進化したかを確認するための、最も純粋な指標になり得ると著者は結論づける。
ドアマンの謬見（びゅうけん）：なぜ不用意なAI導入は裏目に出るのか
https://theconversation.com/the-doorman-fallacy-why-careless-adoption-of-ai-backfires-so-easily-268380
警告する：人間の仕事を「単一タスクの集合」と誤認してAIに置き換える「ドアマンの謬見」が、企業の生産性と顧客体験を毀損している。
AIの導入が急速に進む中、多くの企業が「ドアマンの謬見（Doorman Fallacy）」に陥り、期待した成果を得られずに失敗している。これは、広告エグゼクティブのロリー・サザーランドが提唱した概念で、人間の仕事を「目に見える単純なタスク」だけに還元し、技術で置き換え可能だと誤認することを指す。ホテルのドアマンの役割は単に扉を開けることだけではない。接客、防犯、タクシーの手配、常連客への配慮、そしてホテルの格を維持するという多面的で無形の価値を提供している。しかし、効率化を急ぐコンサルタントは、これらを無視して「自動ドア」に置き換えればコストが削減できると結論付けてしまうのだ。
著者は、現代の企業が従業員の役割を「注文を取る」「電話に応対する」といった表面的なタスクリストとしてしか評価していない点を指摘する。その結果、コンテキストの理解や判断力、職場を円滑にする目に見えない貢献が排除され、自動化の失敗や顧客満足度の低下を招いている。具体例として、オーストラリア・コモンウェルス銀行のAIボット導入による解雇撤回や、米タコベルのドライブスルーAIが引き起こした混乱が挙げられている。調査によれば、AIで従業員を置き換えた企業の55%が「急ぎすぎた」と認めており、一部では解雇した人員の再雇用も始まっているという。
エンジニアやプロダクトリーダーにとっての教訓は、自動化の対象を慎重に見極めることだ。データ入力や予測保守のような、人間による監視が不要でルールに基づいたタスクはAIに適している。しかし、対人サービスや複雑な判断を伴う業務では、AIを人間に取って代わる存在ではなく、人間の判断を補強するツールとして活用すべきだ。著者は、真の効率化とは単なるコスト削減ではなく、顧客体験や長期的な成果を重視することだと主張する。人間が持つコンテキストの理解とAIの処理能力を組み合わせることこそが、無思慮な自動化によるバックファイアを防ぐ唯一の道である。
2025年、AI時代の要件定義について考える
https://syu-m-5151.hatenablog.com/entry/2025/12/27/140231
AIが「作る」プロセスを高速化する時代だからこそ、人間が責任を持って「何を作るべきか選ぶ」要件定義の重要性を説く。
AIエージェントが自律的にコードを生成し、エラー修正やプルリクエスト作成まで担う2025年において、エンジニアの介在価値がどこにあるかを深く考察した論考である。著者は、AIによって「作る」作業が10倍速くなるからこそ、間違ったものを10倍速く作らないための「選ぶ」作業、すなわち要件定義の重みが増していると主張する。
本書の核心は、意思決定を「痛みを伴う責任の引き受け」と定義している点にある。AIは確率的な計算に基づいて最適な選択肢を提示し、メリット・デメリットを列挙することはできるが、その選択が失敗した際の責任を取ることはできない。著者は「痛みのない決断は、決断ではなく単なる計算である」と断じ、不確実性の中で「これでいく」と腹を括り、プロジェクトの責任を引き受けることこそが人間に残された聖域であると説く。
具体的な手法として、IPAの『ユーザのための要件定義ガイド』を引用しながら、「要求（生のニーズ）」と「要件（合意された仕様）」の決定的な違いを解説している。特に、単なる承認（ハンコ）ではなく、当事者が変化を受け入れる「コミットメントの合意」の重要性を強調する。また、ビジネス目標（Why）から具体的機能（What）へとつなぐ「リザルトチェーン」の概念を用い、AIが提示する無限の選択肢から、ビジネス価値を生むものだけを論理的に選別するプロセスの必要性を提示している。
Webアプリケーションエンジニアにとって、本稿は単なる技術論を超えたキャリアの指針となる。AIが実装をコモディティ化する中で、エンジニアは「実装者」から、ビジネスとシステムの橋渡しをする「意思決定者」へとシフトしなければならない。優先順位付け（MoSCoW分析）において「やらないこと」を決定する創造的な棄却や、非機能要件に伴う経営リスクの引き受けなど、AIには代替不可能な「人間臭い」調整能力こそが、これからのエンジニアの武器になると結論づける。
CursorのCEO、中身を確認しない「バイブ・コーディング」の危険性を警告 —— 複雑化で「崩壊」を招く懸念
https://fortune.com/2025/12/25/cursor-ceo-michael-truell-vibe-coding-warning-generative-ai-assistant/
AIに丸投げしてコードの内容を精査しない「バイブ・コーディング」が、長期的な技術的負債やシステムの崩壊を招くリスクを指摘し、エンジニアが詳細を把握し続ける重要性を強調する。
Cursorの共同創業者兼CEOであるMichael Truell氏は、Fortuneが主催した「Brainstorm AI」カンファレンスにおいて、昨今トレンドとなっている「バイブ・コーディング（Vibe Coding）」の危険性について強い警告を発しました。バイブ・コーディングとは、開発者がコードの中身を詳細に確認したり理解したりすることなく、AIに「雰囲気（バイブ）」で指示を与えてアプリケーションを構築させる手法を指します。
Truell氏は、この手法を「床下で何が起きているか、あるいは配線がどのようになされているかを全く確認せずに、壁と屋根だけを積み上げて家を建てるようなもの」と例えています。このアプローチは、ゲームやウェブサイトの簡易的なプロトタイプを素早く作成する場合には有効かもしれませんが、より高度で複雑なプログラミングにおいては致命的な問題を引き起こす可能性があると著者は述べています。
著者の説明によれば、中身を理解せずに「目をつぶったまま」AIに構築を任せると、ソフトウェアの基盤が脆弱（shaky foundations）なものになります。その脆弱な基盤の上にさらに機能を積み重ねていけば、システムが複雑化するにつれて、最終的には全体が「崩壊（crumble）」し始めると警告しています。
これに対し、Truell氏はCursorの役割を、エンジニアが「一歩引いてAIにタスクを任せる」利便性を提供しつつも、同時に「コードの細部（nitty gritty）に深く入り込み、制御を維持する」ことを助けるツールとして位置づけています。CursorはIDE内に統合され、既存のコードベースの文脈（コンテキスト）をAIに理解させることで、精度の高い予測やデバッグ支援を行いますが、それはあくまでエンジニアが中身を掌握していることが前提です。
エンジニアリングの本質が「コードを手で打つこと」から「AIに指示を出すこと」へ移行しつつある中で、依然として「基盤となるコードがどのように動作しているかを理解する責任」は人間にあり、それを放棄することが長期的なリスクを招くという点が、著者の最も伝えたい重要な示唆となる。
代替可能性を欠く「AIプリンシプル・コード」――スチュワードシップ・コードの劣化コピーが日本のソフトローを破壊する
https://takagi-hiromitsu.jp/diary/20251227.html
政府のAI指針案が、金融業界の規範を形式的に模倣しただけであり、実効性を欠く「劣化コピー」として日本のソフトローの信頼性を損なうと警鐘を鳴らす。
著者の高木浩光氏は、政府が公表した「生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（案）」について、金融分野の「スチュワードシップ・コード」を不適切に模倣した「劣化コピー」であると断じている。本記事では、大規模言語モデルを用いた詳細な比較分析を通じて、同案が抱える構造的欠陥を浮き彫りにしている。
著者が指摘する最大の懸念は、最上位目的（プリンシプル）の欠如である。模倣元であるスチュワードシップ・コードには「企業の持続的成長を促す」という明確な上位目的が存在し、各原則はその手段として機能している。そのため、特定の原則を実施しない場合でも、別の手段で目的を達成していることを説明する「コンプライ・オア・エクスプレイン」が成立する。しかし、本AIコード案には「技術進歩」と「知財保護」という対立する価値観の並置しかなく、提示された唯一の手段（開示義務）を代替する手法が他に存在しない。結果として、実施しない場合の「説明（エクスプレイン）」は、透明性を求める権利者に対する単なる「言い訳」や弁明に終始せざるを得ない構造になっている。
さらに、文書の命名や翻訳の質についても厳しく批判している。「プリンシプル・コード」という用語自体が意味の重複した不自然な造語であり、英語版タイトルに至っては文法的に破綻した「Principle-Code」という表記が用いられている。著者は、こうした形式的な権威付けや国際標準を無視した内向きな文書作成が、海外大手事業者への実効性を欠くだけでなく、日本のソフトロー全般の信頼性を末代まで損なう「悪しき前例」になると危惧している。
Webアプリケーションエンジニアにとっても、開発ツールの透明性や学習データの権利関係を規定するルールが、こうした論理的破綻を抱えたまま施行されることは、将来的な法的リスクの不透明化に直結する。著者は、単なる単語の置換ではなく、まず「何のための原則か」という最上位目的を定義し直し、実効性のある代替手段を再構成すべきだと主張する。
Niche Explorations & Deep Dives
LLMの「内部表現」を可視化する：Gemma Scope 2を用いたアニメ・漫画領域での安全性メカニズム検証
https://note.com/cyberagent_ai/n/n111eaa3b772c
疎自己符号化器（SAE）を用いてLLMの内部表現を解きほぐし、アニメ・漫画コンテンツが過剰拒絶される原因が特定の固有名詞の汚染ではなく、カテゴリ認識に伴う安全判定閾値の変動にあることを実証する。
大規模言語モデル（LLM）が、本来クリーンなはずのアニメや漫画の固有名詞に対して「安全性の問題」として回答を拒否する「過剰拒絶（Over-refusal）」の問題に対し、サイバーエージェントのエンジニアが最新の解釈可能性ツールを用いてその深層心理を解剖した。
筆者は、2024年12月に公開された「Gemma Scope 2」を活用し、LLMの内部表現を人間が理解可能な「概念（特徴量）」に分解する疎自己符号化器（SAE）を用いて検証を行った。当初の仮説は「ネット上の膨大な二次創作データにより、固有名詞が直接的にセンシティブな概念と結びついている」というものだったが、実験結果はこの仮説を明確に否定した。Gemma 3 4Bの内部では、有名な版権キャラクター名はそれ自体では性的な特徴量を全く刺激しておらず、むしろ一般名詞（男性、女性など）よりも「安全」と評価されていた。
真の原因として浮上したのは「概念的な隣接」による判定閾値のシフトである。実験②のSteering（概念操作）において、「アニメ・漫画」を司る特徴量を意図的に抑制したところ、境界線上の単語（メイドなど）に対する安全判定の確信度が劇的に向上した。つまり、LLM内部で「アニメ・漫画」というカテゴリが活性化するだけで、安全フィルターの解像度が低下し、「念のため拒絶する」という過剰反応を引き起こしている。
さらに、AIが自動生成した特徴量ラベル（Auto-Interp）の誤りについても言及しており、表面的なラベルに惑わされず生の活性化サンプルを人間が検証することの重要性を説く。
RAGの精度が73%から100%に向上した話 ─ チャンキング戦略の比較検証
https://zenn.dev/oharu121/articles/efd3d038afc6da
社内規程を対象としたRAGシステムにおいて、チャンキング戦略の比較検証を通じて精度を73%から100%へ改善したプロセスを報告し、手法の選択が検索の再現率に与える影響を明らかにしている。
RAGシステムの構築において、多くのエンジニアが直面する「回答精度の停滞」という課題に対し、具体的な比較データを用いて解決策を提示した技術レポートである。著者はNext.js、FastAPI、Gemini 2.0 Flashなどのモダンなスタックを用い、社内規程というキーワード密度が偏りやすい文書を対象に、複数の検索戦略を検証している。
本記事の核心は、RAGの失敗がLLMの性能ではなく、検索（Retrieval）フェーズにおける「Recall（再現率）」の不足に起因することを実証した点にある。著者は、日本の規程文書に特有の「一般規則と例外規定の物理的距離」や「暗黙的参照（『第2条に定める者』がアルバイトを指すなど）」が検索漏れを引き起こすと分析。その上で、標準的な1000文字のチャンキング（精度73.3%）に対し、2000文字の「ラージチャンキング」を適用することで、コンテキストの包含率が高まり精度100%を達成したことを報告している。
特に注目すべきは、精度向上に有効とされる「リランク（Re-ranking）」の導入が、本ケースでは逆に精度を60%まで低下させたという意外な結果である。著者はこの理由を、検索の初期段階で正解チャンクが上位に含まれていない（Recall不足）状態で、リランクによって上位を絞り込む（Precision向上）ことが、結果として正解候補をノイズとして除去してしまったためだと考察している。リランクは「ノイズ除去」のツールであり「検索漏れ」を救うものではないという指摘は、RAG最適化における重要なトレードオフの理解を促すものである。
最終的に著者は、アルゴリズムの複雑化よりも「データ品質とドキュメント構造の見直し」こそが最も強力な改善策であると主張する。従業員タイプごとに文書を再構成するなどの前処理が、複雑な検索手法（Parent-Childや想定質問生成）を凌駕する結果を示したことは、実装コストを抑えつつ高い信頼性を求める開発者にとって極めて実用的な知見である。
exe.dev - AI時代のVM Hostingサービス
https://www.deeeet.com/writing/exe-dev
AIが生成したコードや小規模なツールを、即座に安全な公開環境で実行するための「AI時代のVMホスティング」の重要性と、その具体解としてのexe.devを紹介する。
AIエージェントによる開発が日常化する中で、エンジニアが直面する「生成されたコードや小規模ツールをどこで安全に動かすか」というデプロイの障壁に対し、著者はTailscaleの元CTOが手掛ける「exe.dev」を強力な解として提示する。本記事は、AI時代の「Just in Time Software（必要な時にその場でソフトを作る）」を実現するためのインフラのあり方を鋭く考察している。
exe.devは、従来のVMホスティングの自由度と、モダンなPaaSの利便性を高度に融合させたサービスだ。サーバーレスとは異なりディスクが永続化されるため、SQLiteの運用やパッケージの自由なインストールが可能でありながら、公開ドメインの付与、TLS証明書の自動管理、Emailベースの認証システム（Login with exe）といった煩雑なインフラ作業を自動化している。著者は特に、この「セキュアかつ即座に公開できる」という体験が、デスクトップ環境に閉じないAIツールの活用において不可欠であると強調する。
技術的な特筆点は、VMに統合されたAIエージェント「Shelley」による開発体験だ。Shelleyはexe.devの内部構造を理解しており、ユーザーはチャットを通じてコードの実装から、systemdによるデーモン化、ポート監視の設定までを「Vibe Coding」的に完結できる。著者はこれを、モバイル端末からの音声入力による指示や、移動中の隙間時間での開発を現実のものにする仕組みとして評価している。
Webアプリケーションエンジニアにとって、本記事が示す重要性は、AIによる開発の「ラストワンマイル」である実行環境の確保にある。重厚なクラウドインフラや複雑なk8sを組むほどではないが、ローカル環境では完結しない自動化やWebフックの受け口として、VMという「古くて新しい」選択肢がAIによって再定義されている。
Claude Code用TD Skills - Treasure Data向けAIネイティブCLI
https://tdx.treasuredata.com/guide/td-skills.html
Treasure Dataの操作をターミナル上のAIエージェントで完結させる専用プラグイン群を提供し、データエンジニアリングの効率を極限まで高める。
Treasure Dataは、Anthropic社が提供するAIネイティブなCLIツール「Claude Code」を拡張する専用プラグイン群「TD Skills」を公開した。これにより、開発者はターミナル上で動作するAIエージェントを介して、Treasure Dataのクエリ作成、ワークフロー管理、CDP設定などの複雑なタスクを自然言語で実行・自動化できるようになる。
本ツール群は、データエンジニアリングの実務に即した3つの主要なカテゴリーで構成されている。
1. SQL Skills (`sql-skills`): Treasure Data特有のTrino/Hive関数（`td_interval`や`td_time_range`など）をAIが正しく理解し、クエリの最適化や修正を行う。特に、メモリ不足エラー発生時にTrinoクエリを自動的にHiveへ変換する機能や、パーティションプルーニングを意識した時間フィルタリングの生成など、プラットフォームの特性を熟知したアシストを提供する。
2. Workflow Skills (`workflow-skills`): Treasure Workflow（Digdag）の構文や`td>`オペレータを用いたワークフロー構築をサポートする。dbtとの連携設定やデバッグ、リトライ・バックフィルパターンの提案など、オーケストレーション作業の工数を大幅に削減する。
3. tdx Skills (`tdx-skills`): CDPとしての中心機能であるセグメント作成やジャーニー定義のYAML構成、コネクタ設定などをCLIから直接制御する。また、`tdx agent`を用いて Treasure Data 独自のAIエージェントを構築するためのプロンプト作成支援機能も含まれている。
Treasure Dataによれば、これらのスキルは単なる補助ツールではなく、データ運用におけるコンテキストスイッチを最小化し、AIとの対話を通じて高品質なデータパイプラインを迅速にデプロイするための「AIネイティブなワークフロー」を実現するものだ。`tdx claude`コマンド一つですべてのスキルが統合された状態で起動できるため、エンジニアは環境構築の手間なく即座に高度なAIアシスタンスの恩恵を受けることができる。
Lovcode - AIコーディングツールのためのデスクトップ・コンパニオン・アプリ
https://github.com/MarkShawn2020/lovcode
統合管理する、Claude CodeなどのCLIツールの対話履歴やMCP設定をGUIで視覚化し、AI開発ワークフローの生産性を向上させる。
Lovcodeは、Anthropicが提供するCLIツール「Claude Code」などのAIコーディングツールを拡張・補完するためのデスクトップ・コンパニオンアプリである。現代のAI駆動型開発において、CLIベースのツールは強力だが、過去の対話履歴の参照や複雑なMCP（Model Context Protocol）サーバーの管理、スキルの再利用性といった面でインターフェース上の制約に直面することが多い。Lovcodeは、これらの管理機能をGUIとして提供することで、開発者のコンテキスト切り替えコストを削減し、AIツールのポテンシャルを最大限に引き出すことを目的としている。
技術構成としては、フロントエンドにReact 19とTypeScript、バックエンドにRustを採用したTauri 2ベースのクロスプラットフォームアプリとなっている。特筆すべきは、Tantivyを用いた高速な全文検索機能を備えた「Chat History Viewer」であり、プロジェクトを横断して過去のAIとの対話を瞬時に検索できる点だ。また、~/.claude/commands/ 配下のスラッシュコマンドの管理や、MCPサーバーの統合状態の監視、再利用可能なスキルテンプレートの構築など、単なる履歴ビューアに留まらない「AIワークフローの司令塔」としての機能を備えている。
著者は、AIコーディングを単なる自動生成ではなく、高度にカスタマイズ可能な「エージェントワークフロー」として捉えており、サブエージェントの設定やフックによる自動化、コミュニティテンプレートを共有するマーケットプレイスの提供を通じて、属人化しがちなAI設定をチームやコミュニティで共有可能な資産へと昇華させることを目指している。
さらに、スキルの管理機能では再利用可能なテンプレートを定義でき、特定のコーディング規約や設計パターンをAIに即座に適用させる「プロンプトエンジニアリングの資産化」が可能になる。サブエージェント機能では、カスタムモデルを用いた特定タスク特化型のAIを構成でき、開発プロジェクトのフェーズに応じた柔軟な使い分けを支援する。
ClaudeCode Workflow Studio - Claude Code用ビジュアルワークフローエディタ
https://github.com/breaking-brake/cc-wf-studio
複雑なAIエージェントのワークフロー構築を、ドラッグ＆ドロップの視覚的操作と自然言語による指示で簡素化するVS Code拡張機能を提供します。
Anthropicが提供するエンジニア向けCLIツール「Claude Code」の利用体験を劇的に向上させる、強力なビジュアルエディタが登場しました。この「ClaudeCode Workflow Studio」は、コードを書くことなく複雑なAIエージェントのオーケストレーションや条件分岐を含むワークフローを設計し、そのままClaude Codeで実行可能な形式でエクスポートできるVS Code拡張機能です。
筆者がこのツールを開発した背景には、CLIベースのClaude Codeが持つポテンシャルを最大限に引き出しつつ、エージェント間の連携や条件分岐といった複雑なロジックを直感的に管理したいというニーズがあります。従来、Claude Codeで高度な自動化を実現するには、`.claude`ファイルを手動で記述し、プロンプトやスキルの関係性を管理する必要がありましたが、本ツールはこれをGUI上のキャンバスで視覚化します。
特筆すべきは、単なるドラッグ＆ドロップエディタに留まらず、「Edit with AI」機能を搭載している点です。ユーザーは自然言語で「MCP（Model Context Protocol）を使用してPRレビューを行うワークフローを作って」といった指示を出すだけで、AIがキャンバス上にノードを配置し、ロジックを自動構築します。生成されたフローは、さらに自然言語で「エラーハンドリングを追加して」「出力をSlack形式にして」といった対話形式での微調整が可能です。
技術的な深みとして、Model Context Protocol（MCP）のネイティブサポートが挙げられます。外部APIやデータベース、ブラウザ操作（Playwright等）を行うMCPツールをノードとして組み込めるため、コード生成に留まらない「実務を遂行するエージェント」の構築が容易です。また、条件分岐（IfElse / Switch）やユーザーへの問いかけ（AskUserQuestion）といったノードにより、AIの自律的な判断と人間の介入をシームレスに結合できる設計になっています。
エンジニアにとっての重要性は、開発プロセスにおける「定型的な複雑タスク」の資産化にある。作成したワークフローは`.claude/agents/`や`.claude/commands/`へワンクリックで書き出され、即座にCLIからスラッシュコマンドとして呼び出せる。さらにSlack共有機能も備えており、チーム全体でのワークフロー共有と再利用を促進する。ローカル完結型の設計（MCPサーバー等の外部通信を除く）であるため、セキュリティ面での懸念も最小限に抑えられている。
Technical Deep Dives
2025年のAIエージェント開発の到達点はClaude Code on Bedrock AgentCoreかもしれない
https://qiita.com/moritalous/items/bd4e1cdfadb80b04065a
Claude Agent SDKとAmazon Bedrock AgentCoreを組み合わせ、エージェントの「構築手法」の議論を終結させ、「スキル開発」に注力できる実践的なアーキテクチャを提示する。
著者は、2025年におけるAIエージェント開発の決定打として、Anthropicの「Claude Agent SDK（Claude Codeのライブラリ版）」をAWSの「Amazon Bedrock AgentCore」上でホスティングする構成を提案する。
このアプローチの核心は、エージェントを「どう作るか」という基盤部分の課題をClaude Codeの強力な推論・実行能力とAgentCoreの堅牢な実行基盤で解決し、開発者の関心を「どんなMCP（Model Context Protocol）やAgent Skills（スキル）を実装するか」という付加価値の部分へシフトさせることにある。
記事では、Python版SDKを用いたエージェントの基本実装から、AgentCore Runtimeへのデプロイに必要なDockerfileの構成、さらにStreamlitによるUI実装、MCP対応、CDKによるインフラ構築までを具体的に解説している。特に、エージェントが実行環境内で不用意なコマンドを実行しないためのガードレールプロンプトや、ファイル入出力のハンドリングなど、実運用を見据えたTipsが豊富に盛り込まれている。
著者は、Claude CodeとClaudeモデルの組み合わせが現時点で「地球上で最も強力なAIエージェント」であると評価しており、この構成を採用することで、モデルやツールの進化を即座に自社のエージェントへ取り込める拡張性の高いプラットフォームが手に入ると主張する。最終的に「エージェントの型はこれで決まりではないか」という強い手応えを述べている。
GitHub Copilot Chat の Plan "モード" をコードレベルで理解する
https://zenn.dev/openjny/articles/43e010c65faa9a
解明する。GitHub Copilot Chatの「Plan」モードが、従来の基本モードとは異なり、実は拡張機能が注入する「カスタムエージェント」として実装されていることをソースコードレベルで紐解きます。
GitHub Copilot Chatの「Plan」モードが、Ask、Edit、Agentといった他の基本モードとは根本的に異なるアーキテクチャで構築されていることを、VS Codeの実装レベルから深掘りした記事である。著者はVS CodeおよびCopilot Chat拡張機能のソースコードを調査し、Planモードが従来のインテントベース（プログラム的な制御）ではなく、実は拡張機能が注入する「カスタムエージェント」のラッパーに過ぎないことを明らかにした。
技術的な核心は、なぜPlanエージェントがUI上で「モード」として扱われるのかという点にある。著者の分析によれば、VS Codeには特定の条件（Copilot Chat拡張機能から登録されていること）を満たすカスタムエージェントを、UIコンポーネントが例外的に「組み込みモード」として表示する特別な処理が仕込まれている。これには、VS Codeが持つ「Contribution Points」や「Prompt Storage」というプロンプト管理の抽象化レイヤーが深く関わっており、技術的にはユーザーが作成するカスタムエージェント（.agent.md）と同等の仕組みが、プラットフォーム側の特権的な処理によって公式機能として統合されている。
また、実際のエージェント定義ファイル（Plan.agent.md）の解析も非常に示唆に富んでいる。このプロンプトではXMLタグ（`
エンジニアにとっての重要性は、Planモードの挙動がブラックボックスではなく、私たちが作成するカスタムエージェントと同じ仕組みで動いていると知ることにある。著者は、Planモードの定義ファイルを参考にすれば、特定のプロジェクトや社内ドキュメント、独自のチケット管理システムに特化した「自分たち専用のPlanモード」を構築することも可能だと主張する。
編集後記
メインジャーナルが「今週の動向」を俯瞰するなら、このAnnexは「次の一手」を考えるための地図だ。
LLMのAttention特性を意識したフレームワーク選定、コンテキスト消費を90%削減する環境変数、要件定義の「痛みを伴う責任」、そしてバイブ・コーディングへの警告——これらB面の記事に共通するのは、技術的な深さだけでなく、「AIをどう使いこなすか」ではなく「AIとどう向き合うべきか」という問いへの真摯さである。
今週のAnnex18本は、無批判な導入への警鐘、数理的基盤に基づく実践、そして解釈可能性への挑戦という3つの視座を提供した。主流に乗るだけでは見えない技術の裏側を理解し、自律的な判断を下すための思考の補助線として、これらの「B面」を読み返してほしい。
🤖 本記事は Claude Code を使用して編集されました。