AIコーディング & エージェント 30本
RAG はどう壊れるのか 第6回：評価と失敗モード
ここまで、RAG の部品を順に見てきました。
「もう十分か」を判断するRAG 第4回：Agentic RAG
前回までで、検索ツールを見てきました。
chunk の山ではなく地図を渡す 第5回：PageIndex と階層型検索
前回は Agentic RAG を見ました。
ベクトル検索だけでは足りない ― BM25 / RRF / ハイブリッド検索（RAG 第2回）
RAG を作ると、まずベクトル検索を入れたくなります。
grep が強くなる条件 第3回：Agent 時代の検索設計
前回は、BM25 とベクトル検索を比べました。
【図解】3961本を RAG で運用して分かった ―「検索して答える仕組み」では足りない理由（第1回）
RAGをただのベクトル検索ではなく、「何を見て、どこまで調べてから答えるか」を決める仕組みとして整理する連載第1回です。
ベクトル検索だけでは足りない 第2回：BM25 / RRF / ハイブリッド検索
RAG を作ると、まずベクトル検索を入れたくなります。
grep が強くなる条件 第3回：Agent 時代の検索設計
前回は、BM25 とベクトル検索を比べました。
Claude Code / Codex時代の開発フロー──Plan、Work、Review、CompoundでAIを工程に入れる
この記事は「AIエージェントを工程に入れる」シリーズの第0回です。 Claude Code、Codex、Cursor、Gemini CLI のような coding agent を、…
AIエージェントに渡す仕様書の書き方──巨大な依頼を壊さず小さく渡す
この記事は「AIエージェントを工程に入れる」シリーズの第1回です。 第0回では、Claude Code / Codex 時代の開発フローを Plan、Work、Review、Com…
AIエージェントの仕事をどう検品するか──Trace、Eval、Pre-CI Reviewの考え方
この記事は「AIエージェントを工程に入れる」シリーズの第2回です。 第1回では、AIエージェントに渡す仕様書の書き方を扱いました。 今回は、その後に必ず来る問題、つまり「出てきた成…
一度の失敗を次の成功に変える──AGENTS.md、Memory、Skillの使い分け
このシリーズでは、AIエージェントを「コードを書かせる道具」ではなく、開発工程に入る作業者として扱います。
AIエージェントに実行させる前に──Sandbox、権限、ファイル境界の考え方
AIエージェントにコードを書かせる話は、だいぶ普通になりました。
MCPとToolsをどう考えるか──read-only、write、権限スコープを分ける
AIエージェントは、単体でもかなり動けます。
既存リポジトリ調査で使う──実装前に読ませる、再現させる、止める
AIエージェントに仕事を頼むとき、多くの人はすぐ実装を頼みます。
Codex Appを技術作業台にする──画面、ファイル、thread、reviewの使い方
Codex App は、単なる「チャットでコードを書かせる画面」ではありません。
実戦テンプレート集──Plan、Work、Review、Compoundをそのまま貼って使う
ここまで、AIエージェントを開発工程に入れる方法を分けて書いてきました。
AIエージェント導入の判断基準──任せていい仕事、まだ任せない仕事
このシリーズでは、AIエージェントを開発工程に入れる方法を書いてきました。
委託時代②：FDE――委託時代が生んだ最初の新しい職種
人間が AI を細かく操作するのではなく、まとまった仕事を渡し、進捗を見て、最後に受け取る。道具を使うというより、仕事を委託する関係に近づいている、という話です。
委託時代③：Impact vs Activity――委託時代の職業方法論
コードを書いた量。チケットを閉じた数。会議に出た時間。資料を作った枚数。そういうものは、これまで仕事をしている証拠になっていました。
委託時代④：AI に渡してはいけないもの――Tony Fadell の cognitive surrender
AI に仕事を渡す。企業には FDE が必要になる。個人は activity ではなく impact で測られる。
委託時代⑤：Messy Middle――委託時代の社会の請求書
activity ではなく impact で働いてきたエンジニア。
AI は平気でウソをつく。なのに ClickHouse は、それで百万行の C++ を回している ―― 1年の運用記から見えた、たった一つのカラクリ
懐疑派の最後の言い訳って、だいたい C++ なんですよね。「agent は JavaScript くらいは書けるだろう。でも俺の、まるで原発でも動かしてそうな毛むくじゃらの C++…
How I Use Hermes Agent to Run an Agent Team
これ、モデルの新機能の話じゃない。エージェントを十個動かしたときに本当に詰まる場所の話なんですよね。どのagentがどのrepoを触ってる、どのマシンが空いてる、どのモデル枠がまだ…
AI時代の原型開発は、コードを書く速さより仕事の切り方が効く
これは、AIコーディングエージェントで原型開発がどう変わったかの現場メモとして読める。単にコード生成が速い話ではなく、エンジニアの仕事が仕様を書く、境界を切る、検収する側に寄ってい…
Claudeは「呼び出すモデル」から「働かせる基盤」へ進んでいる
今回のAnthropic開発者イベントで見るべきなのは、新モデル名よりもManaged Agentsと計算資源の確保なんですよね。ClaudeがAPIの向こう側にいる賢いモデルでは…
テストが全部通って初めて褒められるAI ―― Kimi-Dev に学ぶ「コードを直すモデル」の作り方
SWE-bench と「全テスト通過でのみ報酬」という訓練思想から、修正特化モデルの意味を整理する。
「無料で落とせるモデル」が、コーディングで GPT-5.5 に並んだ ―― Kimi K2.6 を読む
オープンウェイトの巨大MoEが、コーディングでクローズドモデルに並ぶ意味を読む。
気づいたら、中国の「オープンなコーディングAI」が一個師団になっていた ―― MiniMax M2.7 を入り口に
MiniMax M2.7 を入口に、中国のオープンなコーディングAIが群れで出てきた構造を見る。
中国のモデルが「コーディングで世界トップ級」に並んだ ―― Qwen3.7-Max を、誇張を外して読む
Code Arena の順位と35時間タスクから、中国モデルのコーディング能力を冷静に読む。
AI工程・実装 44本
Agentic OS 読み替え表 ―― この連載の言葉と、外の世界の名前
この連載は、固有名詞を使わない縛りで書いてきました。製品名も、手法名も、会社名も出さず、できるだけ機構だけで語る。その理由は、「名前を知っている」ことと「仕組みを分かっている」こと…
Agentic OS 技術スタックを下から読む 第26回：権限を「道具」ではなく「能力」に貼る ―― 安全を下から支える許可の設計
前回は、よく働くエージェントほど、言葉でだまされる危険も大きくなるという話で終わりました。社会的にだまされるエージェントを前提にして、権限、確認、経路、監査、停止条件を組み直す、と…
Agentic OS 技術スタックを下から読む 第27回：仕様は、長く書くほど効くわけではない ―― 注意の予算と、段階に割る設計
ここまでは、権限をどう絞るかを見てきました。できる操作を絞り、届く場所を絞り、通ってよい経路を絞ることで、エージェントが越えてはいけない線を下の層から作りました。今回は少し上へ戻り…
Agentic OS 技術スタックを下から読む 第28回：検証は、点数を眺める仕事ではない ―― 失敗の記録を読み、型にまとめる
前回は、仕様をどう書くかを考えました。注意を向けられる量には限りがあります。だから、巨大な一枚の仕様にせず、段階に割ります。関係する分だけ渡します。版を持たせます。そうすれば、やっ…
Agentic OS 技術スタックを下から読む 第30回：外では「あると思われた権限」が会社を縛る ―― 表見の権限と、責任の所在
前回までは、出力をどう測るかを見てきました。
Agentic OS 技術スタックを下から読む 第31回：直せる失敗と、戻せない失敗 ―― 可逆性で操作を分け、戻せない手前で人を挟む
前回は、外の世界の第一面を見ました。 あると思われた権限が、会社を縛るという話でした。
Agentic OS 技術スタックを下から読む 第34回：層を束ねる外殻 ―― モデルを、制御できるループに収める
前回は、ゼロから鍛える手仕事の話で終わりました。静かに失敗する訓練を、一段ずつ確かめる規律です。その規律こそが、この連載の背骨でした。
Agentic OS 技術スタックを下から読む 第35回：一体では見えない危険 ―― エージェントが網になると、何が壊れるか
前回までで、土台から外殻までを一巡しました。
Agentic OS 技術スタックを下から読む 第36回：走りながら、経験から学ぶ ―― 教訓を積む記憶と、間違いも焼き付ける記憶
前回は、安全の網を見ました。エージェントが一つの道具ではなく、いくつもの処理につながる網になると、失敗もまた網の中を進みます。小さな誤りが広がります。弱い判断が増幅されます。信頼し…
Agentic OS 技術スタックを下から読む 第37回：物差しは古びる ―― 静的な評価が、いつのまにか失効する
前回は、走りながら経験から学ぶ記憶を見ました。
Agentic OS 技術スタックを下から読む 第38回：委譲とは、文脈を切り離すこと ―― 重い探索を別の頭に任せ、結論だけ持ち帰る
前回は、物差しが古びる話をしました。
Agentic OS 技術スタックを下から読む 第40回：同じ能力でも、渡し方で変わる ―― 編集という一手で読む、道具の設計
前回は、読むことと書くことの非対称を見ました。読むだけなら、すでにあるものをたどれます。書くときは、まだないものを一語ずつ生む必要があります。だから高くつきます。
Agentic OS 技術スタックを下から読む 第42回：タスクは終わったのに、あなたの取り分は守られていない ―― 代理人としてのエージェント
前回は、検証できない好みの教え方を見ました。結びでは、次回はまた別の層の急所へ降りる、と書きました。今回は、そのまま外の現場へ戻ります。
Agentic OS 技術スタックを下から読む 第44回：文脈の窓は、ノートではない ―― 溜めるほど悪くなる、だから絶えず整える
前回は、世界モデルが抽象の層で先を読む話をしました。結びでは、次回はまた別の層の急所へ降りる、と書きました。
Agentic OS 技術スタックを下から読む 第45回：取り込んだものは、あなたの権限を受け取る ―― 依存とサプライ網の信頼
前回は、文脈の窓をどう手入れするかを見ました。広げるだけでは足りません。何を残し、何を捨て、何を近くに置くかで、エージェントのふるまいは変わります。
Agentic OS 技術スタックを下から読む 第46回：長い鎖を、崖から守る ―― 外に状態を出し、一段ごとに確かめ、戻れるようにする
前回は、取り込みの信頼を見ました。外から入ってくるものを、どう受け、どう疑い、どう使える形にするかを見ました。結びでは、次回は、また別の層の急所へ降りる、と書きました。
Agentic OS 技術スタックを下から読む 第48回：下から読み終えて ―― スタックを貫く、いくつかの背骨
言葉だけのエージェントは、目と耳を他人に借りているようなものです。
Agentic OS 技術スタックを下から読む 第49回（最終回）：下から読み終えた人へ ―― 何を学び、何を練習するかの地図
エージェントとは、賢い一個ではない。層の重なりです。
Agentic OS 技術スタックを下から読む 補講(1)：外の知識を、その場で引く ―― 意味で探すと、名前で外す
前回、第49回で、私は「この連載は、ここで閉じる」と書きました。
Agentic OS 技術スタックを下から読む 補講(2)：専用の口がないとき、画面を使う ―― 見て、押して、打つ
前回は、外の知識を引く話でした。
Agentic OS 技術スタックを下から読む 補講(6)：補講を貫く、同じ背骨 ―― そして、ここで閉じる
ここで、補講も閉じる。
Agentic OS 技術スタックを下から読む 補講(13・終)：いつ動き、いつ待ち、いつ眠るか ―― エージェントと時間、そして連載を閉じる
前回は、前置きを取っておいて、また使う話をしました。
Agentic OS を、取引で読み直す（0）：賢さは、無数の取引の上に立っている ―― 部品ではなく、取捨を軸に読む
前の連載では、土台から上へ、部品を一つずつ読んできました。算力、本体、運び方、覚え方、束ね方、守り方、測り方、現場での取り回し。下から順に見ていくと、見晴らしはよくなります。
Agentic OS を、取引で読み直す（1）：入口は広く、出口はせまく ―― 誤って弾く損と、誤って通す損は、釣り合わない
前回、取引を軸に読み直すと宣言しました。部品を並べるのではなく、何を許し、何を諦め、どこで払うかを見る、と書きました。
Agentic OS を、取引で読み直す（4）：割れる計算、割れない揃え ―― 手分けの得は、足並みで払う
前回までは、一つの場所で、軽く速くする取引でした。
Agentic OS を、取引で読み直す（7）：委ねるほど、確かめる手綱が要る ―― 自分の答案を、自分で採点させない
前回まで、一つのモデルの中の取引を見ました。ここからは、そのモデルに、仕事をまるごと任せる側へ移ります。
Agentic OS を、取引で読み直す（9）：小さな漏れが、掛け算で崩れる ―― 一段の信頼は、つなぐ数の上で効く
前回まで、一つ一つの取引を見ました。最後の一組は、それらを組み合わせて、長い段取りを作るときに、立ち上がります。
Agentic OS を、取引で読み直す（10・終）：どの取引にも、ただ飯はない ―― 賢さは、無数の取引の上に立っている
九つの取引を、見終えた。別々の層の、別々の話に見えた。だが、どれも、同じ一つの形をしていた。最後に、その形を取り出して、この連載を閉じる。
Agentic OS 技術スタックを下から読む 第0回：エージェント基盤はなぜ OS に近づくのか
この一年で、「エージェント」という言葉の重心が変わった。
Agentic OS 技術スタックを下から読む 第11回：手を動かさせる前に ―― サンドボックスという「縛られた実行環境」
ここまでの回では、主にモデルそのものを見てきた。
Agentic OS 技術スタックを下から読む 第12回：エージェントの記憶 ―― 保存ではなく「なぜそうしたか」を残す
前回は、エージェントに手を動かさせるための実行環境を見た。
Agentic OS 技術スタックを下から読む 第13回：一体から複数へ ―― 難所は「間」にあり、実行ツリーで見る
前回まで見てきたのは、一体のエージェントをどう安全に走らせるかだった。
Agentic OS 技術スタックを下から読む 第14回：段を重ねるほど崩れる ―― 信頼性の崖と、編成の型
前回は、複数のエージェントが動くとき、その難しさは個々の点よりも「間」に出る、という話をした。
Agentic OS 技術スタックを下から読む 第15回：道具の呼び出しは、分散システムへの呼び出しである
前回は、L4 の編成を「長い鎖を短く区切る」ものとして見た。
Agentic OS 技術スタックを下から読む 第16回：注入攻撃 ―― なぜ、データを読むだけで乗っ取られるのか
ここまでの数回で、エージェントを「賢い」だけのものから、「任せられる」ものへ近づけてきた。
Agentic OS 技術スタックを下から読む 第17回：注入をどう防ぐか ―― 指示とデータの、硬い境界
前回は、注入がなぜ効くのかを見た。
Agentic OS 技術スタックを下から読む 第18回：本当にできているか、どう確かめるか ―― 答えではなく「たどった道」を読む
ここまで、エージェントをどう作るかを下から見てきた。
Agentic OS 技術スタックを下から読む 第21回：指標は、目標になると壊れる ―― エージェント評価の根の罠
第18回では、エージェントの評価は、最終出力だけを見ることではない、と書いた。どの道を通ったか。どこで迷ったか。失敗が偶然か、構造的なものか。それを読むことが評価の中心になる。そして、合格率が高すぎる評価は、むしろ警告だとも見た。
Agentic OS 技術スタックを下から読む 第23回：同じ作業場を、共有させない ―― 隔離で並行を成り立たせる
第13回では、複数エージェントの不具合は、一体の中ではなく、エージェントとエージェントの「間」に出ると見た。原因の多くは、共有する資源での衝突だった。
Agentic OS 技術スタックを下から読む 第24回：記憶を、どこに持つか ―― 文脈・外部検索・小さな状態
第12回では、記憶とは、ただ保存することではなく、「なぜそうしたか」という因果を残す土台だ、と見た。あれは、何を残すかの話だった。
Agentic OS 技術スタックを下から読む 第25回：社会的に、だまされる ―― 有能なエージェントほど詐欺に弱い
L5 では、まず注入を見た。外から命令を送り込み、エージェントの判断を曲げる攻撃である。次に漏洩を見た。断片的な情報が、意図しない形で外へ出ていく攻撃である。
企業AIエージェントは、まずデータ基盤を片づけないと働けない
企業AIエージェントのデモは簡単です。チャット欄に「先月の売上を地域別に出して」と打つ。モデルがSQLを書く。表とグラフが出る。拍手。
LLM評価の本質は、ダッシュボードではなく失敗を読むことだ
LLM評価という言葉を聞くと、多くのチームはすぐに基盤を作ろうとする。評価基盤。メトリクス。ダッシュボード。自動採点。LLMasajudge。
How we contain Claude across products
AIエージェントを仕事に入れるとき、もう「賢いか」だけでは足りない。 どこに閉じ込められていて、何に触れてよくて、どこから外に出られるのか。 Anthropic が Claude.…