『作って学ぶAIエージェント』を書きました ── TypeScriptでコーディングエージェントを自作する本

技術評論社のエンジニア選書から、新刊『作って学ぶAIエージェント ──TypeScriptとLLMで切り拓くAI時代のエンジニアリング』を出しました。2026年4月20日発売、紙版・電子版が同時に出ています。

作って学ぶAIエージェント | 技術評論社

ソフトウェア開発の世界では「AIエージェント主導のコーディング」が主流になろうとしています。エージェントはコードを生成するだけでなく、ファイルを読み、コマンドを実行し、テストを実行し、結果を確認し、必要に応じて修正を繰り返します。 本書は、こうしたAIエージェントのしくみを「使う」のではなく「作る」ための実践的なガイドです。最終的にはGitHubのIssueを起点に、コードの修正からプルリクエストの作成までを自動化するコーディングエージェントを実装します。扱う技術はTypeScriptとBunを中心にし、GitHubへの統合までを扱います。 ここでは、エージェントの動作原理、つまり思考のしくみを自ら実装し、挙動の予測と制御、目的に合わせたカスタマイズを扱います。 実装するAIエージェントは、筆者が「Nano Code」と名付けたものです。LLM APIとの接続、ファイルやコマンドを扱うツール、思考ループ、Git操作、実用環境への統合といったレイヤーを章ごとに積み上げ、最終的に実用的な自動化まで進みます。章を追って段階的に構築し、コーディングエージェントとして機能する流れを整理します。 対象読者は、TypeScriptでアプリケーションやコマンドラインツールを作った経験があり、AIエージェント開発やLLM活用に関心があるエンジニアです。TypeScriptとLLMを軸に、AI時代のエンジニアリングの実践手法を解説します。

技術評論社著者

なぜこの本を書いたのか

Claude Code、Codex、Cursor──こうしたコーディングエージェントは、すでに筆者の毎日の開発フローに組み込まれている存在です。「使う」側からの解説書としては、すでに良書が多く出ています。たとえば筆者自身も買って読んだおすすめの2冊があります：

• 『Claude CodeによるAI駆動開発入門』（平川知秀 著、技術評論社、2025年12月）── これからClaude Codeを使い始めたい方向け
• 『実践Claude Code入門 ──現場で活用するためのAIコーディングの思考法』（西見公宏・吉田真吾・大嶋勇樹 著、技術評論社、2025年12月）── 業務に組み込みたい方向け

本書は、これらと並べる「使う側」の本ではなく、コーディングエージェントの中身を自分の手で組み上げるための本です。

モデル性能とコーディング性能が直結しない違和感

筆者は2025年9月にベンチマークプロジェクト ts-bench を公開しました。ちょうど Claude Code が「急にアホになる」現象がエンジニア界隈で話題になっていた時期の直後で、Cline → Claude Code → Codex CLI → Gemini CLI、と矢継ぎ早に登場するコーディングエージェントを横並びで比較しながら、ある違和感が積み重なっていきました。

それは、モデルそのものの性能が、コーディングタスクの性能に直結しないのではないか？　という疑問です。同じモデルでも、エージェントの実装（ハーネス）を入れ替えると挙動が大きく変わる。逆に言えば、ハーネスを変えるだけで「いままで賢く動かなかった構成」が突然動き出すことすらある。

この感触を言語化したかったのが、本書を書こうと思った最初の動機です。

"前世代"のエージェント設計が、いまも提案され続けている

もうひとつ、書き始めてから気づいた問題があります。

ChatGPT や Gemini に「AIエージェントを作りたい」と相談すると、返ってくる答えはだいたい ReAct論文（2022）由来のアーキテクチャです。LangChain 初期のエージェント設計はこの系譜にあって、Python エコシステムはその上に多くを蓄積してきました。

これは筆者の体感の範囲の話ですが、おそらく学習データの偏りが原因でしょう。その時点のモデル性能から逆算された方法論が、現代のモデルに対してもそのまま提案され続けています。今から振り返ると、当時はモデルの足りなさを実装層が補っていました。Reasoning と Acting のチェーン分割、出力テキストのパース、思考トリガー──こうした処理が、フレームワーク側のコードとして書かれていました。これらは tool use（function calling）、structured output、reasoning モードといった LLM API 側の進化に吸収されていき、もうアプリ側のコードとして書く必要のない処理が一段ずつ増えてきました。

一方、コーディングエージェント世代で新しく加わったレイヤーもあります。ファイル読み書きやコマンド実行といった、OS レベルの抽象を「ツール」としてエージェントに渡す形が定着しました。ReAct 論文の Reasoning / Acting というやや抽象的なループに対して、コーディングエージェントは Read / Write / Edit / Bash といった具体的なツールセットを前提に組まれます。ここはむしろアプリ側で実装する範囲が増えた領域です。本書で扱うのは、こうした引き算と足し算のあと──2025年に急速に発展したアーキテクチャのほうです。

象徴的なのは、Anthropic が 2025年9月にそれまでの「Claude Code SDK」を「Claude Agent SDK」にリネームしたことです。コーディングエージェントとして作られたハーネスが、そのままビジネス向けエージェントやドメイン特化エージェントの基盤として使えると判断された解釈の拡大、と読めます。コーディングエージェントは、すべてのエージェントを内包しうる基礎技術になってきている──というのが筆者の見立てです。

コーディングエージェントは、別の系譜で進化した

Anthropicの社内には Cat Wu氏が関わった「Clide」（※OSSの Cline とは別物）というPython製GUIの先行プロジェクトがあった、と公開インタビュー（Cat & Boris インタビュー動画）で語られています。これは、コードをインデックス化していて起動に1分かかるツールで、Boris Cherny氏（2024年9月Anthropic入社）が同僚に勧められて試し、「一発でコーディングタスクを完成させる」可能性に感銘を受けたといいます。

その後、Cherny氏がターミナルでAnthropic APIをプロトタイプしていた折、「Clideみたいなものを作りたい」とCLIで小さな試作品を作った──これがClaude Codeの最初のプロトタイプです。CLIを選んだ理由は「UI設計を省略して、APIを学ぶ最も安価な方法だったから」。つまり Cherny氏自身が、まさに「作って学んでいた」わけです。

このツールはAnthropic社内で急速に広まり、2025年2月の「Claude Code」リサーチプレビュー公開、Maxプランでの課金整備、5月の Claude 4 と同時の一般リリースへとつながっていきました。この段階でコーディングエージェントユーザーが職業プログラマーの間でも一気に広がりました。

OSS側で、それ以前からコーディングに特化したターミナル型エージェントとして長く使われ続けているのは aider です。そして Cline が、エージェントアーキテクチャを TypeScript／Web フロントエンドの実行環境に持ち込んだことで、「エージェントはモデル開発とは独立した、アプリケーション層で勝負がつくもの」「Cursorのようなアプリケーションを自作できる」という認識が定着しました。Codex や Gemini CLI も同系統の流れで発展していきます。

この「ターミナル型コーディングエージェント」という形態は、論文が発祥ではなく、こうした実装の蓄積で定まってきました。本書はこの現代の系譜のほうの設計を基盤にしています。前世代の貢献（ReAct パターンを実装に落とし込んで広めた LangChain など）も尊重しつつ、いまの設計の流儀を上書き更新するための一冊になることを目指しています。

筆者自身はLLMのモデル開発者ではありませんが、OSSのコーディングエージェントを追い続けるうちに、設計の世代交代が起きていることに自然と気づきました。だからこそ書ける本だと思いました。

Nano Codeとは何か

ニッチな技術書にもかかわらず、t-wadaさんはじめ、発売後は思っていた以上に多くの方に手に取っていただいています。

ここで本の中で何を作るのかを説明します。本書で実装する Nano Code は、Claude Code、Codex CLI、Gemini CLI など現代のコーディングエージェントと同種のしくみを持つ独自の小さなエージェントです。命名は Andrej Karpathy 氏の nanoGPT などの Nano シリーズへのオマージュで、最小の部品単位に分解したコーディングエージェントという意図を込めています。Claude Code のクローンでもフォークでもありません（Claude Code 自体は Anthropic 製のクローズドソースです）。

3つのコンポーネントに分けて段階的に組み立てます。

• nano-code-core：OpenAI / Anthropic / Google のLLM APIを統一インタフェースで扱う抽象化レイヤー（第3章）
  • Vercel AI SDK Coreのような基盤
• nano-code-cli：ローカル実行環境（第4〜6章）
  • claude -p の部分を再現したもの
• nano-code-action：GitHub Actions統合（第7章）
  • Claude Code Actionのインテグレーション部分

最終形は、GitHub Issueの作成をトリガーに、ファイル読み書き → コマンド実行 → Git操作 → PR作成までを自動化するワークフロー。開発者の操作は「Issueを書く」と「PRをレビューする」だけになります。実際に動いている様子はサンプルリポジトリのissuesで確認できます。筆者自身が日常的にこの仕組みで遊んでいます。

技術スタックは TypeScript + Bun + Dev Container。Webエンジニアの延長で書ける構成にしていて、Pythonと機械学習の知識は前提にしていません。これも本書の特徴です。

章ごとのハイライト

第3章：マルチプロバイダの差分を、なぜVercel AI SDKに任せないか

OpenAI / Anthropic / Google のSDKは使いつつ、その上の抽象化レイヤーは自作する、というのが本書の方針です。

理由は、モデル各社の差別化要因がAPIに直接出ているパラメータや追加機能にあるからです。たとえば OpenAI の Responses API への新機能の出し方や、Anthropic が anthropic-beta ヘッダで先行公開する各種機能（このあたりはClaude Code の「ソースコード流出」をどう見るのかという記事のなかでも観測された範囲で触れています）。Vercel AI SDK のような厚い抽象化に任せてしまうと、こうした"モデルの個性"にアクセスしづらくなります。

第3章で実装する抽象化レイヤーは、これらの差分を最小限の薄い層で吸収する設計になっています。読み終えると、各社のAPIドキュメントを読んだときに「ここが差別化要素か」が自分で見抜けるようになります。

golden_lucky さんの「解説書として LLM API という切り口があった」という観察は、書いた本人として嬉しい読まれ方でした。AIエージェントの自作という形で、結果として LLM API の教科書にもなっている、というのは意図したことのひとつです。

第5章：思考ループはどう作るか

第5章では、Nano Code の「頭脳」にあたる思考ループを、1 段ずつ積み上げて作ります。1 往復の会話 → 会話のループ → ツール実行の統合 → 承認ポリシー（HITL）→ 無限ループ防止 → Agent クラスへの再構築、という順序です。

エージェントにとって一番重要なコンポーネントはこのエージェントループと呼ばれるパーツだと考えています。Simon Willison はAgents are models using tools in a loopで、エージェントを「ツールをループで使うモデル」と定義しました。第5章で実装するのは、この定義をそのまま動くコードに落とし込んだものです。

第7章：Issue から PR まで自動で動かす

Issue 駆動で自動 PR を作るワークフローを、5 行の YAML から始めて段階的に組み上げます。gh CLI による PR 作成、自動承認モード（--yolo）、再実行への対応（固定ブランチ＋PR 更新）まで、実運用に必要な要素を一通り扱います。

実際に各社のエンジニアリングブログで紹介されている「ハーネスエンジニアリング（要出典）」としての自動化事例は、Slack やチャットツールをトリガーにして、クラウドのサンドボックス上で開発を自動化する仕組みが多い印象です。本書で扱う GitHub Actions 構成は、その手前の最小単位として読めると思います。Issue というすでにある入り口を使うので、GitHub だけあれば成立し、Slack / Bot / サンドボックス基盤を別途用意する必要もありません。

第8章：サンドボックスの作り方

本書最大の「実運用への踏み込み」が第8章です。コーディングエージェントを動かす環境を、Docker（基盤インフラ）／bubblewrap（プロセス隔離）／TypeScript（アプリケーション制御）の3層で守る設計を実装します。章末では、ファイルシステム攻撃／ネットワーク攻撃／破壊的コマンドが実際に無力化されることを手元で確認します。

ここはまだ正解のない領域で実験的です。実際にClaude Coworkのオフィスワーカー向けのインターフェイスではVMによるサンドボックスが提供されていたり、Codex Appではホスト向けのアプリケーション操作などに踏み込んでいたりと、各社の取り組みは異なります。

写経で組み上がる体験

章を進めるごとに Nano Code が一段ずつ動くようになる構成にしました。短いハンズオン単位に区切っているので、限られた時間でも進められます。

overlast さんの「大学の実験の教科書に近い」という形容は、書いている時に筆者自身も意識していた手触りでした。各章の冒頭に「これまでの振り返り → 今章で作るもの → 次のステップ」を入れたのは、まさにそういう"実験の教科書"のリズムを作りたかったからです。

threecourse さんが「久しぶりに写経をした」と書いてくださっていますが、写経は写経で価値があると思っています。guru_meya さんのように、写経を入口にして自分の言語で再実装する読まれ方も嬉しい。設計自体は言語非依存で書いたので、Go 版・Rust 版・Python 版を作るのにも十分使える内容になっているはずです。

参考になるプロジェクト

本書は2025年内に書き上げました。その後にも、似た問題意識から生まれた取り組みが各所で動き出しているので、参考になりそうなものを並べておきます。

落合陽一氏が公開した ochyai/vibe-local は、Python 標準ライブラリだけで書かれた約 7,400 行の単一ファイル vibe-coder.py と、Ollama + Qwen3 による完全オフラインのコーディングエージェントです。「Claude Code に Claude Code を作らせた」というメタ的な誕生経緯と、README に日本語・英語・中国語に加えて「やさしい日本語」まで揃えた構成からは、ご本人の講義で学生に "作って学ぶ" を体験させるための教材として組まれている、と読めます。

TypeScript 側でも、Mario Zechner 氏の pi-coding agent（@mariozechner/pi-coding-agent）が、Read / Write / Edit / Bash の 4 ツールだけで構成されたミニマルなフレームワークとして公開されています。OpenClaw（OpenClawの何が特別なのか？ という記事で紹介しました）のような実践的な OSS プロジェクトで実装基盤として採用されており、Nano Code 的な "基板を持つエージェント" を作る場合、出発点として有力です。

背景にあるのは、おそらく構造的な話だと筆者は捉えています。自動化をもう一段進めようとすると、自分で実装するレイヤーを下げていく必要があります。既存のエージェントツールを「使う」位置に留まっていると、自分のワークフローに合わせた粒度で自動化を組むのが難しい。そこで、もう一段下のレイヤー──エージェントのハーネスそのもの──を自作する動きが、各所で同時多発しているように見えます。

本書は、こうした流れの中で、TypeScript で順に組み立てていくための入門書として読んでもらえると思っています。

公開技術レビューと、執筆の苦労話

本書の制作スタイルでは、技術評論社の「[作って学ぶ]」シリーズ──hikalium 氏『[作って学ぶ] OSのしくみⅠ』、d0iasm 氏『[作って学ぶ] ブラウザのしくみ』──を強く意識しました。リポジトリで実装を進めながら本で解説し、発刊後も継続的にアップデートできるモデルです。本書のタイトル『作って学ぶAIエージェント』は、この系譜へのオマージュでもあります。

このスタイルの良さは、本書にあえて入れなかった機能──たとえばサブエージェント機構や、コマンドラインのターミナル対話 UI など──を、発刊後に差分コンテンツとして追加していける点にもあります。実装はリポジトリに足し、解説は別記事として書く。書籍そのものは出発点として残しつつ、扱う領域だけを少しずつ広げていける。既刊2冊を見ていて、改めて良いやり方だなと思いました。

2026年1月、年始の約1週間、原稿段階でこの本の公開技術レビューを実施しました。20名を超える方に GitHubリポジトリ へ参加いただき、Google フォームで記名・匿名どちらでもフィードバックを受け付ける形式です。観点は3つ──(1) 技術的に致命的な誤りの検出、(2) 説明の前提不足や誤解を招く表現の指摘、(3) 現行ツール・APIとの不整合の確認。

そして執筆中、一番苦しかったのは、公式ドキュメントのある解説書と違って本書には正解がないことでした。自分で考えた意見を本という形で世に出すプレッシャーが終始ありました。間違っているかもしれない、セキュリティ問題のある設計をしてしまうかもしれない。そのプレッシャーをかなり受け止めてくれたのが、レビュアーの方々です。当初は技術観点のピンポイントなレビューを募集していたつもりでしたが、実際には技術チェックを超えて、コンセプトや文章構成といった編集者レベルの観点までフィードバックをいただきました。原稿の枠を超えた助けを受けた、というのが正直なところです。残った問題は著者の責任として──サポートサイトで随時、正誤を更新していきます。

執筆の自動化断念

書き始めるとき、エージェントを自律的に動かして本書そのものも自動執筆できないか、と試しました。先行事例にはインスピレーションを受けました。たとえば、広木大地氏の『AIエージェント 人類と協働する機械』は35万字を1か月強で、著者がタイプした文章が1行もない"AIによって書かれた本"として刊行されています（レバテックLABのインタビュー）。広木氏は複数のAIエージェントに役割分担をさせて「組織」のように動かし、「全体設計してから磨き上げる削り出し型」のプロセスを採ったそうです。及川卓也氏の新刊『プロダクト倫理』も、プロデューサー・リサーチャー・ライター・校正者・読者というAIエージェントチームを編成して制作しています（XCrossing ep178）。

しかし結論から言うと、筆者の場合はうまくいきませんでした。理由は、書籍内容の破壊的な構造の入れ替えが頻繁に発生したからです。実装を変えるたびに本文の対応箇所も書き直す必要があり、「どの機能を本に含めるか」の判断が最後まで難航しました。エージェントにライティングを任せると、本全体としての一貫性が大きく崩れた文章になってしまう。とくにサンプルコードと本文の説明の整合性が、回を重ねるごとに崩れていくのが致命的でした。コードを直すと本文が古くなり、本文を直すとコード例とずれる。執筆していた時点では、エージェントチームやオーケストレーションする層も、それを支えるモデルの性能も、長文書籍の自動執筆をやりきるにはまだ届いていなかった、という側面もあったと思います。これは反省点として残っています。

最終的には泥臭く、自分で書いて訂正を繰り返しながら、AIにはレビューだけを任せる形に切り替えました。それでも稚拙な文章が残っていたら、それは筆者の筆力の問題です。

本書で何が得られるのか

本書を読み終えると、Claude Code / Codex / Cursor を「使う」目が変わると思います。プロンプト、ツール、コンテキスト、権限──エージェントを成り立たせている要素の単位で挙動を見られるようになる。「同じモデルでもエージェントごとに性能が違う理由」が、ようやく自分の言葉で説明できるようになります。

第9章では、ここから先のエンジニアの役割について書きました。コードを書くことそのものではなく、指示と制御の設計、コンテキスト設計、権限と環境設計が、これからの中心的な作業になっていきます。自律性と制御のトレードオフを引き受けながら、どこに人間が介入するかを決めることになります。

そして、本書で実装した設計は言語非依存です。Go でも、Rust でも、Python でも、考え方はそのまま持っていけます。本書で TypeScript と Bun を選んだのは、まさにこの「言語に縛られない設計を見せやすい」ためでもあります。TypeScript のビルド・コンパイル・実行という文脈で、Bun はオールインワンの単一バイナリとしてある時点のTypeScriptビルド環境のスナップショットを提供してくれています。Node.js + tsc + ts-node + esbuild + ... のような活発に更新される組み合わせを毎回選び直す手間に注意を奪われずに、エージェントの設計そのものに集中してもらえます。AI 時代のサンプルコードの最大公約数として、TypeScript はいまもっとも読者層が広い言語のひとつだ、という判断もありました。

終わりに

作って学ぶAIエージェント | 技術評論社

ソフトウェア開発の世界では「AIエージェント主導のコーディング」が主流になろうとしています。エージェントはコードを生成するだけでなく、ファイルを読み、コマンドを実行し、テストを実行し、結果を確認し、必要に応じて修正を繰り返します。 本書は、こうしたAIエージェントのしくみを「使う」のではなく「作る」ための実践的なガイドです。最終的にはGitHubのIssueを起点に、コードの修正からプルリクエストの作成までを自動化するコーディングエージェントを実装します。扱う技術はTypeScriptとBunを中心にし、GitHubへの統合までを扱います。 ここでは、エージェントの動作原理、つまり思考のしくみを自ら実装し、挙動の予測と制御、目的に合わせたカスタマイズを扱います。 実装するAIエージェントは、筆者が「Nano Code」と名付けたものです。LLM APIとの接続、ファイルやコマンドを扱うツール、思考ループ、Git操作、実用環境への統合といったレイヤーを章ごとに積み上げ、最終的に実用的な自動化まで進みます。章を追って段階的に構築し、コーディングエージェントとして機能する流れを整理します。 対象読者は、TypeScriptでアプリケーションやコマンドラインツールを作った経験があり、AIエージェント開発やLLM活用に関心があるエンジニアです。TypeScriptとLLMを軸に、AI時代のエンジニアリングの実践手法を解説します。

技術評論社著者

• 書籍ページ：作って学ぶAIエージェント | 技術評論社
• 紙書籍：技評Direct / Amazon
• 電子版：Gihyo Digital Publishing / Kindle
• サンプルコード：laiso/nano-code
• サポートサイト：laiso.github.io/nano-code（正誤情報あり）

感想・指摘は X またはサポートサイトの Issue までお寄せください。

謝辞

本書の制作にあたり、原稿段階でのレビュー、発売後の感想・指摘でお世話になった皆さまに、深く感謝いたします（敬称略・順不同）。

• yasaichi
• 寺嶋祐稀（@y-temp4）
• naotaka1128
• 内川浩典
• aliyome
• staticWagomU
• buchi
• togami2864
• 川口大翔
• satetsu888
• 藤井祐行
• yukukotani
• ML_Bear
• 大庭直人（@ohbarye）
• komura-c
• 藤野慎也
• gigun-dev
• morinokami
• Zaka-Ko
• takuya-itoh

そして、記名・匿名を問わずレビューにご協力くださったすべての方々に、改めてお礼申し上げます。