AIエージェント登場におけるジュニアエンジニアの研鑽について

はじめに

いつも楽しみにしている fukabori.fm のPodcastで 131. AIコーディングの現在地 w/ twada 回を聴いていて、もう少し具体的に深掘りして自分の成長に繋げたいなと思う部分があったので、整理してみる。

ジュニアエンジニアが今後どのようにスキルを磨いていくか

1:06:10辺りから該当する話が始まります。

ここでは、シニアエンジニアとジュニアエンジニアの違いの一つとして「設計判断力」の有無を挙げている。

AIエージェント登場前のシニアエンジニアはこのスキルを、自身が設計＋実装したものを自身でメンテナンスし、その過程で得た失敗や成功などの「しっぺ返し」で鍛えてきたそう。 またその「しっぺ返し」は、約半年程度かけて受けることが多かったそうだ。

ただしAIエージェントの活用で、この期間を約1週間程度に短くできる可能性があるそう。（1週間が大事ではなく、圧倒的に短くできるがポイント）

これにより自身の設計判断した答え合わせの回数が増えることで、飛躍的に鍛えるスピードが向上させることが期待できると考えられる。 ここで強く意識したいのは、AIの提案を鵜呑みにせず一緒に考え、自分で意思決定した結果で痛い目を見て、経験を意図的に積むこと。

ここまで話を聞いて自分は、以下の疑問を持った。

• AIエージェントのお陰で具体的に「何が」短くなったのか
• そして、どう上手くしっぺ返しをくらえるか

ここからは、上記の疑問を少し整理していこうと思う。

AIエージェントのお陰で具体的に「何が」短くなったのか

まずはAIエージェント登場前の開発サイクルを確認してみる。
ここでは前提として個人開発に焦点を絞るので、本当にざっくりとした工程で分類。

1. 要件整理
2. 設計
3. 実装
4. 運用

この工程を繰り返す中で、具体的には「2. 設計」「3. 実装」辺りで機能要件系や変更に対するコストのしっぺ返し、「4. 運用」で非機能要件系のしっぺ返しがくるようなイメージ。

ではここからAIエージェントを登場させる。
今回のPodcast内でいくつかAIエージェント登場による変化を話していた。
上記の工程に影響がありそうな話をまとめ、どのように影響を与えたのか整理してみる。

• 設計フェーズ
  • 議論相手としての活用
    • 膨大な知識量を持つため、様々な観点から提案が可能に
  • 語彙を通じた設計意図の伝達
    • こと細やかにコンテキストや解決手段を与えるのではなく、該当語彙（Kent BeckのTidingやt-wadaのTDDなど）を与えることで適切な設計意図の伝達が可能に
• 実装フェーズ
  • 高速な実装コード生成
    • こちらは想定通り
  • 高速なテストコード生成
    • 実はこちらも多大な影響を与えている
  • ドキュメント作成
    • 一例として、英語でのドキュメント生成に一役買っているそう

ここまで整理すると、AIエージェントによって「何が」短くなったのか見えてきそう。

つまりAIエージェント前後での変化は、以下の通りかなと考えた。

• 設計フェーズ
  • 前
    • 自身が扱える（理解している）設計の知識を元に考える
    • 扱えない（理解していない）設計の知識は、事前に蓄える（手を動かして経験し、理解する）必要がある
  • 後
    • 自身が扱えない（理解していない）設計の案を提示してもらい、様々な観点から比較が可能に
    • 扱えない（理解していない）設計は、自身の文脈にあったサンプル実装を並列で生成させ、手元で比較することが可能に
    • 該当語彙を用いて、素早くより適切な設計を提案可能に
• 実装フェーズ
  • 前
    • シンプルに自分の手を動かして実装
  • 後
    • AIエージェントに実装してもらう

「何が」の部分には、まず「実装」が入りそう。そして「設計の壁打ちや提案、比較検証」も入るかなと考えた。
なので、この部分がAIエージェントによって短くなったと理解した。

そして、どう上手くしっぺ返しをくらえるか

自分はここがモヤモヤを持った部分。どうやったら上手くしっぺ返しをくらえるかイメージできなかったので整理してみる。

先ほどのフェーズで一番大事なのは恐らく「設計フェーズ」だと考えている。
それは、上手にしっぺ返しをくらうには「自分で意思決定」する必要があるからだ。

ただしこの意思決定を自分のものにするには、「理解」が非常に重要だと思う。 だが、AIエージェントを使って設計案の提示やサンプル実装を生成させたところで、本当に理解して自分で意思決定できたと言えるのだろうか？
自分はそう思えなかった。AIにマイクロサービスにしましょうとか言われても、今この瞬間に自分で意思決定をしないといけない時に、今から理解しますはちょっと違うと思う。（練習なら別）

もちろん自分の使い方が悪いというのもあると思うが、自分で手を動かさずに理解ができるのだろうか？と。
また、これはAI時代には古い考えなのかも、と不安になることもあったが今のところこの考えはあまり変わってない。

なので、どう上手くしっぺ返しをくらえるかは「ある程度理解している設計を自分で意思決定し、簡単な実装は任せ、設計判断などにFBが返ってくる部分の実装は自分で行うこと」を意識して、自分で手を動かして理解＋試行錯誤できるかどうかかなと考えた。
どんな設計判断力を鍛えたいかなどスコープを定義していないので、何にでも当てはまることではないと思うが、基本はこんなイメージ。

そして次はどうやってこの「ある程度理解している設計」を手札に用意できるかが、大事なポイントになると考えている。
Podcastでは「AIと一緒に考える」とあるが、その為の土台を作るイメージ。
こちらもさっきの話と繋がるが、その土台を作るには「AIを使いながら、自分で手を動かしてある程度理解をする」ことが大事なのかなと考えた。

終わりに

Podcastの内容を自分で理解しようとすると、以下のキーワードが必要だと考えた。

• 自分で手を動かして理解し、AIと一緒に考える土台を整える
  • まずはAIと一緒でもいいので、対象の理解から
• 設計判断などにFBが返ってくる部分の実装は自分で行う
  • 設計判断によるしっぺ返しを肌身で感じるなら、自分で実装を行う
  • 変更やテストがし辛いなど設計判断のしっぺ返しをくらうイメージ

これらのキーワードを取り入れたサイクルは以下のようになり、これが高速道路を走りしっぺ返しを上手にくらう方法なのかなと。

1. 自分で設計判断できる最低限の理解をする
2. AIと一緒に手札にある設計で考える
3. 自分で設計判断をする
4. 簡単な実装を任せ、設計判断などにFBが返ってくる部分の実装は自分で行う
5. 次の要件を整理し、AIと一緒に手札の中から設計判断をする（先ほどの設計判断のしっぺ返しをくらうイメージ）
6. 実装 ...繰り返す

モヤモヤしていたのは、どうやってAIが出す設計案を適切に自分で意思決定ししっぺ返しを高速に受けれるようになるのかイメージできなかった為。
そしてその解決策は、手を動かして先にある程度理解するに落ち着いた。

正解を見つけたとは思ってないが、一旦こんな整理で。

CodexのLocked computer useを触ってみた

はじめに

5月21日にCodex app 26.519のアップデートがあり、その中に気になる項目があったので早速触ってみた。
いくつか勘違いしていた点などがあったので、そちらも整理しておく。

CHANGELOG

developers.openai.com

このアップデートの中で、Changelog 上では Remote computer use として紹介されている機能が気になった。
詳細ページでは Locked computer use と説明されているので、以下では Locked computer use と呼ぶことにする。

Locked computer use

Remote computer use, so Codex can use desktop apps after your Mac locks, including remotely via Codex Mobile. Codex scopes locked use to active, trusted computer use turns and includes safeguards such as short-lived authorization, covered displays, relock on local input, and manual-unlock fallback.

機械翻訳：
リモートコンピュータ操作機能により、Macがロック状態の場合でも、Codexはデスクトップアプリケーションを使用できます。これにはCodex Mobileを介したリモート操作も含まれます。
Codexはロック状態のコンピュータ使用を、アクティブで信頼できる操作環境に限定し、短時間限定の認証、カバーされたディスプレイ、ローカル入力による再ロック、手動ロック解除時の代替手段などの保護機能を備えています。

詳細リンク↓ developers.openai.com

これが上手く使えると、Mac miniなどを追加で買わずにMacBookでそのままCodexを動かせるんじゃないか？という期待があり、気になっていた。
今までこうした常時起動の使い方をしておらず、そもそも活用のアイディアが出てこないため、今回を機に色々実験したい。

設定

自分の環境では、ドキュメントに書かれている通りの設定をすればいいだけだったので、割愛。

ハマったポイント①：ロックとスリープを勘違い

これはシンプルに自分の勘違い。ロックとスリープは違う。Locked computer use は、Mac がロックされていても本体が起きている状態で使う機能で、スリープ状態では動かない。
なので手癖でスリープにして、「動かない！」とならないように注意が必要。

ハマったポイント②：電源接続をしておく

①と少し似ていて、今の私のMacは常時起動の設定を何もしておらず、いわゆるデフォルト寄りの使い方。
その状態だと、画面ロック後に放置したり、蓋を閉じたりするとスリープ状態になってしまい、動かなくなる。
公式説明に「電源接続が必須」と明記されているわけではないが、自分の環境では電源接続しておくことが実質的に必要そうだった。

ハマったポイント③：それでもシステムスリープする

電源接続し、蓋を閉じずに開いておき、ロック状態にするとスマホから操作が可能になった。
ただし一定時間経つと「PC is reconnecting」というメッセージがスマホに出て操作ができなくなる。

恐らくシステムスリープに入って接続が切れたので、「電源接続時のシステムスリープを無効化」することで安定しそう。
この設定にすると、MacBook を Mac mini 的に、常時起動に近い形で使える可能性があると考えた。（Mac mini を持っていないので、厳密な比較はできない）

さいごに

一旦ここまで設定ができると、自分の環境では正常に動いたので、もし誰かの参考になれば幸いです。

設計ナイト2026に行ってきた！

はじめに

去年に引き続き、2026年4月10日に設計ナイトに参加してきた。
約1年で自分がどこまで成長できたかを知れる機会だと考えていたので、これが一番の楽しみだった。

素晴らしい発表だらけでしたが、この記事では特に自分の仕事や考えていることに焦点を当てて書いていく。

https://kichijojipm.connpass.com/event/383313/

「アーキテクチャモダナイゼーションとは何か」 by nwiizoさん

speakerdeck.com

技術・事業・組織の3つを同時に考えないと結局元に戻るので、具体的にどういう軸や視点で現実から目を逸らさずに向き合い続けられるかといった内容が紹介されていた。

またこの発表で使われているからといって完璧にそれぞれをそのままトレースせずに、ちゃんと自分たちと向き合ってくださいと終始おっしゃっていたのが印象的だった。

加えてレガシーシステムへのリスペクトも凄く心に残っている。
仕事でもレガシーと呼ばれているシステムがあるが、このシステムは会社にとって大きな貢献をしているので、こうしたマインドを持つ重要性を改めて感じられた。

これらを踏まえて、特に刺さったポイント1つ目が「組織図を変えても組織は変わらず、文化が組織を変える」の部分。
組織図を変えても以前と変わらないと感じたり、逆に別チームでは楽しくかつ少し挑戦的なことができ全員が成長していると感じることがあったが、まさにこの「文化（によるチーム全員の振る舞い）」が大事なのかもと最近考えていたので、刺さった。
前職では指示以外の事をすると怒られていた人が、うちのチームに入り少しづつ自分のタスク以外で改善活動をするようになったのを間近で見ていたので、良い組織良いソフトウェアを開発するためには、どういう文化をみんなで築き上げるのかは凄く大事な観点だと思う。

2つ目は「作れるからといって作るな」。
これは少し文脈が違うかもしれないが、コーディングエージェントを使える今、自分で小さなリファクタリングや改善を大量にこなしていたが、レビュアーへの負荷や費用対効果の面で本当にこれで良いのだろうかと最近考えていた。
本当に事業やチーム貢献、顧客への価値につながっているのか？自己満足じゃない？と考えていたので、勇気を持って手を止めて改めて考え直す良い機会になった。

こうした技術や事業だけじゃなくて組織の話も最近気になってきたので、この本買って読みたい。

「悪い設計 <やつ> ほどよく残る ー 「なんでこうなっちまうんだ？」を掘り下げる」 by moznionさん

最近Skillsやハーネスなどの開発におけるガードレールの話が盛り上がっているが、1周回って結局ソースコードしっかりシンプルに綺麗にした方が良くない？？？って思ってたので、かなり刺さる発表だった。

また善意の割れ窓についても、自分は恐らく新卒1年目でやってしまっていて、自分より先輩の方が見えてたり考えていることがあるだろうから、こっちの方がいいかってコードを書いていた時期があり、それを思い出していた。

加えて、人間側の設計知識や嗅覚などはまだまだ必要なので、引き続き強くなっていく必要があるなと改めて強く感じた発表だった。

「制約を設計する – 非決定性との境界線」by soudai1025さん

speakerdeck.com

非決定性の話で、LLMと人間を同じように考えるために抽象化している部分に衝撃を受けた。
めちゃくちゃ面白かった。

まだまだちゃんと理解できていないので、何回も見返したりAIエージェントやソフトウェアを作りながら噛み締めて楽しめるスルメ資料だと思う。

どうやってソフトウェアで制約を作り境界を設計するかは腕の見せ所だと思うし、面白い部分だなと感じた。
またゴールに導く手法では、特にテストコードは大事だと考えていて、最近API実装時にAPIテストで振る舞いを準備しておき、そのテストがALL PASSになるまでコーディングエージェントに自律的に修正してもらう事をやっていたので納得感があった。
上記が振る舞いの話なので、あとは構造をどうするかだがAPIテストがしっかりあればリファクタリングも多少怖くないと思うので、良い循環が生まれるのでは？と考えている。
で、これらに加えるならさっきも出てきた「ソースコードのシンプルさ」だと考えている。

「感情を設計する」 by ナカミチカズシさん

speakerdeck.com

最初らへんの話は難しかったが、チーム内の衝突の話が特に刺さった。
「みんな善意でやるけどプロセスが整ってないから対立する」の話が本当に分かり過ぎて頷きまくってた。
最近コーディングエージェントを活用し、広い範囲で多くの改善ができるようになったからか、チーム内の改善活動で顕著にこれが見られるようになったと感じていた。
例えば誰かの目標設定になっているのに、個人の善意による改善の結果その人の目標が達成できなくなって泣く泣く目標を変えたりとか。
こんなの誰も嬉しくないし黙ってやったもん勝ちになり、改善したいな〜と思っていたので、上司に話して解決していきたい。（別に個人の善意による改善を邪魔したい訳じゃないので）

まとめ

やっぱり今年も行ってよかった！！！！！！！！！
約1年越しの自分の変化も楽しめたし、何よりもっと設計上手くなりたい！という気持ちを再確認できたのがよかった。 加えて、色んな種類の設計を楽しそうに発表している方やそれを笑いながら会場にいたみんなで楽しめたのも、なんだか一緒に設計を楽しむ仲間がいる感じがして凄く良かった。

来年も参加します！！

コンテキストエンジニアリング（弁当）本を読んだ

はじめに

気になっていた弁当本を読めたので、感想を。

gihyo.jp

ちなみにこの本は汎用的なAIのコンテキストの考え方や使い方ではなく、紹介する技術がLLMアプリの開発・運用でどう応用されているかという観点で理解することが前提であることをお忘れなく。

目次

• 各章の感想
• さいごに

1章

最初はLLMの仕組みからの解説。
概要から以下の流れで処理をしていることを理解した。

1. Tokenize
2. Embedding
3. Self-Attention
4. Feed Forward

よく聞くTransformerの説明もしていたが、正直ここはあまり理解できていないと思う。
DeNAのLLM勉強会の時も思ったが、機械学習周り何もわからない。

あと面白かったのが「ロール指定」。
あくまでLLMはユーザーの入力の続きを生成しているだけなので、ここでロールを指定することで対話をしているようにする、というのは驚いた。

機械学習を研究していた人や日頃AIエージェント開発をしている人からすると当たり前かもしれないことを、丁寧に学べた章だった。

2章

2章では実際にOpenAIのAPIを使って、基本的な使い方から考え方、LLMアプリの開発に必要なツール利用、構造化出力、コンテキストキャッシュの仕組みなどが紹介されていた。

手を動かさずに見てしまったので、どこかで小さいAIエージェント作ってみたい。
あと最近OpenAIのResponses APIが大きく変更があったので、そこも併せて読み進めたい。

openai.com

Function CallingとMCPの整理ができていないので、ここは自分の宿題。

3章

この章は日頃AIエージェントを開発していないが、ClaudeCodeやCodex CLIは利用している人にもかなり学びが多い章となる。

どういったプロンプトを作るべきかを丁寧に解説しているが、個人的に最近1番重要だと考えているのが「明確な完了条件」の記述。
これがあることで勝手に自律的に修正サイクルに入ってくれるので、可能であれば必須で入れたい。

例えばAPI実装なんかだとイメージしやすくで、in-outでいくつか仕様を満たすケースを明確にし、API実装後に全ケースを流してそのまま修正させることが可能になる。
TDDとは違うと思うが、明確な完了条件（＝全ケースがAll Green）があることで勝手にログなどを見て修正してくれたり確認を出してくる。
自分のチームでは、OAS（Swagger）からcurlで叩けるファイルをGradleタスクで自動生成し、AIエージェントがエンドポイントを叩きやすくしている。かつSkillにエンドポイント確認まで任せた上でPRを作成してもらっている。

これはOpenAIの中の人も使っている方法だと聞いて、自信が付いた。

他にも「モデルの進化を信じて、HOWよりWHY+WHATを記述する」や「LLMにプロンプト作成を手伝ってもらう」なども行なっていたので、これも自信が付いた。

4章

この章はRAGの説明。
自分は「RAG＝ベクトル検索」と勘違いしていたので、この章はそんな誤解を解消してくれる解説を丁寧に行なっている。

前半の全体像や基盤技術の解説までは付いていけたが、後半の工夫の部分はまだ理解が怪しい。
様々な工夫や色んな種類のデータをどう扱うかは、具体的なケースを挙げて考えないとしっくりこないと感じた。

恐らく「検索（RAGでは参照に近いらしい）」が相当難しいんだろうなという印象を受けた。
そもそもどうデータを用意するかの部分であったり、何を捨てるかの意思決定もこの本には詳しく書かれていないが、実務では必要になってくるんだろうなと。

5章

この章では「AIエージェント」と「ワークフロー化」に焦点を当てた解説を行っている。

日頃AIエージェントを開発している人は理解できると思いますが、そうでない人はやはり手を動かして理解する章だなと感じた。

具体例を用いてエージェントワークフロー設計を開発しているので、自分は「情報収集エージェント」や「脆弱性調査エージェント」を設計するときに見返そうと思う。

ただ単に褒めて持ち上げるだけでなく、メリットが薄い場合や改善を繰り返すことが大事など現実もちゃんと伝えてくれるので、大変ありがたいと感じた。
AIエージェントの独自開発のコラムが大好き。

さいごに

これから何度も見返す本。
実際にLLMのAPIを用いてAIエージェントを開発する際もそうだが、コーディングエージェントを利用していても活用できる考え方がいくつも解説されているので。

あとは実際に自分で何回もAIエージェントを作った方が理解が早いと思うので、早く作りたい。

DeNAのLLM勉強会資料をやってみた

はじめに

DeNAのAIエンジニアである吉田さんが、LLM勉強会の資料を2025年12月に公開してくださった。
この資料は、「AIをコアとしたプロダクト作り」のために必要な知識や問題を詰め込まれた内容になっている。
個人的にもClaudeやChatGPT、GeminiをはじめCLI型のAIエージェントを使って仕事をしているが、こうした観点から学んだことは無かったので凄く興味があり進めてみた。

この記事ではその過程で学んだことや感想を書いていく。

紹介ブログ

engineering.dena.com

資料

dena.github.io

勉強用リポジトリ

github.com

前半

LLMの仕組みから始まり、Instruction Tuning、Reasoning、プロンプトエンジニアリング、ハンズオンが含まれている。

基礎知識

ハンズオン以外の項目はなんとなく知ってるけどよく分かって無かった自分には丁度いい入り。
プロンプトの解説で「長いと人間が把握できなくなる」は、入力結果の評価のためにも大切な考え方だなと感じた。

ハンズオン

ハンズオンに関して、まず初めてGoogle AI StudioやGoogle Cloudを使ったので、かなり手こずった。
今自分がGoogle AI Studioを使っているのかGoogle Cloudを使っているのか、VertexAIを使っているのかなど今でも正直完璧に理解してない。

あたふたしながら、今回はGoogle AI Studio経由でGemini APIを利用した。

この項目で面白かったのが、「構造化出力」
LLMのどう出力してくるか分からない不確実性を、ここで強制することができるんだ！と言う当たり前の発見と、後続処理へ上手く引き渡せるなという感覚が楽しかった。
ただ、ここで構造を決めるとその先の処理が依存してしまうので、どう設計するかは難しいと感じた。

加えてdescriptionもかなり精度に関わってくるので、ここの工夫し甲斐があるなと考えていた。

構造化出力の学習ログ

github.com

また複数のLLMで手分けして、作業をするワークフローの演習も楽しかった。
直列と並列で3倍ほど速度が変わったり、temperature を変えて結果が少し変わる様子を確認できたのも良かった。

解説を見て、評価のログを多めに出しどう判断しているのかなども確認。
評価するときは証拠として出しておいた方がいいが、本番ではデータ量や帯域、通信量なども考えてどうバランスを取るんだろうと考えていた。

複数LLMの学習ログ

github.com

後半

ファインチューニングや強化学習、パーソナライズの内容が含まれている。

知識

ファインチューニングと強化学習の比較では、正直強化学習の部分が全然分からなかった。
企業などで利用する場合は、可能な限りハルシネーションを抑制した方がいいし、有害な回答の回避、様々なAIリテラシーに対する曖昧な指示への対応はファインチューニングより重要じゃないかと考えた。
だからLLMを使う企業はプロンプトチューニングとファインチューニングに加えて、強化学習もしたいんじゃないかと。

と思っていたけど、これはあくまでモデルを「育てる」時にやることなので、出来上がったモデルを上手く使うなら上の2つが必要なんだよと、Claude Codeに教えてもらった。
ただの妄想だけど、今後超小さいモデルの素材が出てきて自分たち特化で育てるとなると、かなり良いモデルを利用できる？？評価がとても大変か。

知識編の学習ログ

github.com

その後はRAGやReAct、Reflexionの説明。
Reflexionの評価者はどうやって評価をするのか、反省者はどう反省すると目的に沿った動きになるのかなどをClaudeやChatGPTと話しながら考えていた。
ここの評価基準をRAGというか外部記憶に上手く整理できているとループがかなり安定するんだろうなとか、ベクトル化しちゃうと読めないかも？？とかを考えていた。

ここら辺の話は、自分でワークフローやエージェントを作る時に再度戻って確認したい内容だった。

ハンズオンはE2まで進めた。

さいごに

この資料を手を動かしながら読み進めたことで、こうしたLLMやエージェントの学習ハードルがとても下がった。
読むだけじゃ体験できない「全く同じリクエストなのに違う結果が返ってくる」「判断基準ちゃんと書くと、安定してくる」などを肌感を持って経験できたのが良かった。

また演習問題があったのも学習を進める上で0から自分で問題を考えずに、理解に集中できた。この資料を作成＋公開してくださった吉田さんに感謝。
次は「AIエージェント 開発/運用入門」本などを読みたい。

Agent Teamsをsubagentsの上位互換だと誤認して、設計思想の学び方を学んだ話

目次

• はじめに
• 時系列での整理
• 学んだ設計思想の整理
• おわりに

はじめに

前回の記事で「Agent Teamsとsubagentsの使い分け」を書いたが、その過程で設計の学び方に関する学びがあったので、整理する。
ある設計について、登場背景や目的、役割の違いを調べて理解し、さらに抽象化するところまで到達できたのは初めてで、自分の中でとても新しい体験だった。
正直、こういう学び方に苦手意識というか一種のコンプレックスがあったので、いつでもここに立ち戻って振り返りができるように記録する。

時系列での整理

並列作業の仕組みとして、両者の比較と誤認

元々subagentsを利用して並列実装を行なっており、上司との会話で、途中で口出しできないのが辛い、という内容を話していた。
なのでAgent Teamsが登場した時【同じ並列作業】ができ、かつ【途中で口出しができる】という特徴から、上位互換だと誤認。

今までの自分だと、ここで追加調査をせずに上位互換と誤認したAgent Teamsだけを使う選択肢を取っていた。
だが今回は、チームメンバーに共有することを前提に検証していたので、裏取りのために追加調査を行なった。
振り返ると、まずはここの起点がよかったかもしれない。

構造とトレードオフを調べる

Agent Teamsを調べていると、「アンカリング防止」が重要なキーワードだと理解。
その過程でsubagentsの問題の一つに「アンカリング」があり、【この構造が常に】問題を引き起こしていると勘違い。

トレードオフと問題を分けて考える

ただよく調べてみると、構造のトレードオフが常に問題になるわけではなく、不適切に利用することで、そのコストが露わになると気付いた。
つまり、subagentsやAgent Teamsを【利用したら必ず】そのコストを払うわけではなく、適切に利用することでこのコストを極力小さくすることが可能な状況を作れる。
なのでsubagentsの「アンカリング」の問題が出やすいのは、段階的な実装で設計判断が入ったり探索的なタスクを行う時。

正しく利用する

subagentでは問題になりやすいタスクに対して登場したのが、今回のAgent Teamsだとここで初めて腑に落ちる。
つまり方針や設計がまだ決定的ではなく、徐々に調査しながら都度修正を行ったり、別エージェントとの協働が必要な課題を解決するために設計されたと理解。
そのための「共有タスクリスト」「メンバー間通信」「ファイルロック」といった機能が備え付けられていると推測。
なのでこの時点で同じ並列作業ができはするが、解きたい課題がsubagentとそもそも違うとわかった。

最初の誤認の訂正

つまり登場タイミングが後で、同じ並列作業ができ、かつ途中で口出しができるから、勝手に上位互換だと考えていたが、それは間違い。
別の問題を解くために登場した機能だと理解。
振り返ると、自分は『なぜ両方あるのか』という問いを起点に、構造の違い → トレードオフ → 適した場面の順で理解を深めていた。

学んだ設計思想の整理

時系列で語った学びの結果を簡潔に整理すると以下になる。

subagents

• 構造
  • 親エージェントにのみ結果を返す一方向の構造
• トレードオフ
  • メリット
    • コンテキストウィンドウの分離
    • モデルの使い分け
    • ツール権限のスコープ制御
  • デメリット
    • アンカリングバイアス
    • コンテキストの断絶と情報劣化
• 適した状況
  • 結果を互いに共有する必要がなく、焦点を絞った作業をする時
  • 大量の出力を生成する操作をする時

Agent Team

• 構造
  • メンバー同士が直接やり取りできる構造
• トレードオフ
  • メリット
    • アンカリングバイアスの軽減
    • 自律的な調整を行う並列作業
  • デメリット
    • トークンコストの爆発
    • 調整オーバーヘッド
    • 同一ファイル編集の競合リスク
• 適した状況
  • 仮説の相互反証が必要なとき
  • 作業中に発見を共有する必要があるとき

まとめ

• 新しい技術は、登場背景・目的・どんな状況で活きるかといった設計思想を正しく理解することが大事だと腑に落ちた
  • そのためには既存技術との比較で掘り下げるなどの工夫が必要
  • 特に「問い」の立て方が重要だった
    • 「なぜ上位互換ならsubagentが消えてないのか」
    • 「なぜ並列作業という文脈で選択肢が2つ残っているか」
    • 「なぜメンバー間通信があるのか」
• 同時に、自分が解こうとしている問題の性質を正しく理解すること
  • 今回のケースでは、探索も共有も不要なCRUD実装だったのでsubagentsが適していた
  • 技術の特性を知っていても、目の前の問題を見誤ると選択を間違える
• 今回学んだことを踏まえて公式ドキュメントを読むと、ほぼちゃんと書いてあった
  • だが体験を伴わないと読み飛ばしたり理解できない内容なので、しっかり手を動かすこと

この学び方がいいのか正直よく分かってないが、小さな成長のきっかけが経験できたと思うので、引き続き強くなるために頑張る。

Agent Teams と subagents はどう使い分ける？並列作業で試して分かったこと

目次

• きっかけ
• 検証条件について
• 結論
• 判断軸
• 今までの方法紹介
• 検証内容と結果の共有
• 判断軸ごとの比較
• 実務での使い分け指針
• まとめ

きっかけ

最近、事業にとってノンコアの比較的簡単な CRUD API を並列実装する検証を行っており、従来は Claude Codeのsubagent とgit-worktree （＋ agent-memory skill ）で進めていた。
そんな中、一昨日 Claude Codeから Agent Teams がリリースされたため、同じ並列作業の枠組みとして試してみた。

検証を通じて、Agent Teams のチーム間共有は「分担をスムーズにするため」だけではなく、同じ対象を複数の独立した視点で検証し、お互いにチェックし合ってアンカリングバイアスを防ぐという意図があることに気づいた。
一方、CRUD のようにゴールが明確で依存関係も読みやすいタスクでは、アンカリングバイアスを防ぐことよりもコスト効率と単純さが重要になる場面も多いと理解した。

本記事では、両者の検証を通じて分かった使い分けの基準や気付きなどを整理する。

検証条件について

本記事では、2種類のタスクを異なる条件で扱っている点に注意してほしい。
どちらも git-worktree を用いた並列作業を対象としている。

• 今までの方法紹介
  • ノンコアの比較的シンプルな CRUD API 実装
  • 機能を実装することがメインで、事前のコンフリクト管理や設計判断が重要
• Agent Teams の検証
  • 初めて試したので、簡易タスクで検証
  • Spring Framework のビルド定義（ gradle ）に対する簡易調査タスク
  • 読解と要約がメインで、並列で動くかどうかやツールがどう動くかを見るのが目的

そのため、本記事は厳密な比較検証ではなく、実際に試してツールの特性を理解するためのものとする。

結論

Agent Teams は、同じ対象を複数の独立した視点で検証し、お互いにチェックし合いたい場面で有効だと感じた。
特にアンカリングバイアスを避けたい場合に向いている。

一方、依存関係が明確でゴールが定まっている並列実装であれば、subagent の方がシンプルかつコスト効率が良い。

判断軸

本記事では、Agent Teams と subagent の使い分けを、次の3つの観点で比較する。

1. ゴールの明確性
   1. 事前にタスク分割・依存関係を確定できるか
2. メンバー間の調整価値
   1. 実行中に相談・確認・方針変更の横展開が必要になり得るか
3. コンテキストとコスト
   1. コンテキストの膨らみ方とトークン消費をどこまで許容できるか

今までの方法紹介

これまで私は、 subagent + git-worktree + agent-memory skill を組み合わせて並列実装を行ってきた。
大まかな流れはこんな感じ。

作業の流れ

1. 既存実装の仕様を整理して、agent-memory skill で記録
2. Plan mode で、新規実装の仕様整理・実装計画を作成
3. git-worktree でブランチを切り、subagents を並列起動
4. 各ブランチ毎の成果物で PR を作成

分かったこと

• git-worktree により物理的なコンフリクトは回避できた
• 仕様整理時点で既存との差分を洗い出し、plan mode で設計書を作成したことで、スムーズに並列作業に移れた
• 事前にコンフリクトしそうな箇所を整理し、実装順を設計したことも、スムーズに並列作業できた要因

検証内容と結果の共有

次に、Agent Teams + git-worktree を用いた検証で分かったことを書く。

検証内容

初めての検証のため、簡単なプロンプトで実施。

Agent Teams 機能を使って spring-aop ディレクトリと spring-context ディレクトリの spring-xxx.gradle の中身の要約をルートディレクトリに text.md に記録して。
コンフリクトすると思うので、git worktree を使ってブランチを切ってそれぞれで各チームメイトが作業してね。

詳細ログは一番最後に

分かったこと

• チームリーダーが worktree とタスクを準備してメンバーを立ち上げて、各メンバーは独立した環境で並列に作業していた
• split-pane mode により、実行中のメンバーへ入力できることを確認した
• 簡単なタスクの割に使用制限の枠が大幅に減った

判断軸ごとの比較

ここでは、subagent と Agent Teams を3つの判断軸で比較し、実際にどう使い分けるかを整理する。

比較サマリー

判断軸	subagent	Agent Teams
ゴールの明確性	事前計画が重要（依存関係が見通せていればうまくいく）	途中で調整できる（依存関係が後からわかっても対応しやすい）
メンバー間の調整価値	横連携なし（各エージェントが独立）	横連携あり（途中介入・通信が可能）
コンテキスト/コスト	軽量（低コストに寄りやすい）	重量（高コストに寄りやすい）

① ゴールの明確性（事前にタスク分割・依存関係を確定できるか）

git-worktree を併用することで、ブランチを物理的に分離しながら並列作業を進められ、並列化自体はどちらでも可能だった。

差が出るのは、事前に作業をどこまでちゃんと分けられるか。
subagent は各エージェントが独立して動作するため、依存関係が分かっているほど期待通りに進む。
一方で、実装中に「ここも触る必要があった」と分かった場合、途中で方針を変えたり作業を分け直すのが難しく、詰まりやすかった。

Agent Teams も事前分割が明確なタスクをちゃんと並列実行できることは確認できた。
加えて、後述の通り実行中に介入・調整できる余地があるため、依存関係が後から判明するケースでは比較的扱いやすいかもしれない。
ただし今回の検証は要約タスクであり、実装のような依存関係の変化をちゃんと再現できていない点に要注意。

② メンバー間の調整価値（アンカリング対策や実行中に相談・確認・方針変更の横展開が必要になり得るか）

subagents はエージェント同士がお互いの存在を知らないので、実行中に相談・確認・調整を行う仕組みがない。
そのため、作業が独立している間はスケールするが、途中で判断が必要になった瞬間に詰まりやすい。

一方 Agent Teams は、split-pane mode により実行中のメンバーに介入できることを確認した*1。
また公式ドキュメントから、SendMessage によるメンバー間通信や共有タスクリストで進み具合を共有できるらしく、チーム内で調整しながら進める設計になっていることを確認した。*2

繰り返しになるが今回のタスクは単純な要約作業であり、メンバー間で調整が発生する場面は観測できなかった。
よって調整のための仕組みがあって、途中介入も可能ではあるが、この機能がより複雑な並列作業でどれだけ効くかはわからない。

③ コンテキストとコスト（コンテキストの膨らみ方とトークン消費をどこまで許容できるか）

コスト面は、両者の差が一番出る。

subagent は、サブエージェント定義ファイルのシステムプロンプトを中心に独自コンテキストで動作すると公式ドキュメントに書いてある。*3
そのため、親セッションのコンテキストが膨らみにくく、かつ subagent 間通信なども無いため、単発タスクを低コストに回しやすい設計だと思う。

一方 Agent Teams は、複数の Claude Code インスタンス（= 独立したセッション）を連動させる機能だ。
各メンバーが独立したコンテキスト／会話履歴を持つ構成に加え、共有タスクリストやメンバー間通信で連携する前提なので、並列化するほどコンテキストとトークン消費が増えやすい（subagent よりコストがかかる設計になっている）。*4

このため「結果だけ欲しい単発タスク」では subagent を、「同じ対象を複数視点で検証しながら進めたいタスク」では Agent Teams を選ぶのが効率的な使い分けだと思った。

実務での使い分け指針

今回の場合だと、こんな感じで subagent と Agent Teams を使い分ける。

subagent が向いているケース

• [ ] ゴールが明確で、事前に作業分割を確定できる
• [ ] 実行中の横連携や方針変更はほぼ不要
• [ ] 単発の調査・解析、または結果だけ欲しいタスク
• [ ] トークンコストを極力抑えたい

すべて当てはまるなら、subagent + git-worktree を選ぶと良さそう。

Agent Teams が向いているケース

• [ ] 複数視点でお互いにチェックし合う（アンカリング対策）に価値がある
• [ ] 実行中の確認・相談・方針変更が起き得る
• [ ] 依存関係が途中で変わりうる
• [ ] コスト増を許容できる

複数に当てはまるなら、Agent Teams + git-worktree を試してみる価値がある。

まとめ

本記事では、並列作業の検証として subagent と Agent Teams を、「ゴールの明確性」「メンバー間の調整価値」「コンテキストとコスト」の3軸で比較した。
並列化自体はどちらでも可能だが、並列化の"前提"と"運用コスト"がどっちを選ぶかの分かれ目だと分かった。

また機能の背景をしっかり理解することで、より良い使い方ができるようになる感覚を得たのが今回の最大の収穫だったのかも。
あと今回のまとめなどは公式ドキュメントにしっかり書かれている内容でもあったので、自分で手を動かして検証しつつしっかり読み込むことも大事だなと気付かされた。（手を動かさないと理解できないというのはあると思う）

実際のログ

❯ Agent Teams機能を使ってspring-aopディレクトリとspring-contextディレクトリのspring-xxx.gradleの中身の要約をルートディレクトリにtext.mdに記録して。
  コンフリクトすると思うので、git worktreeを使ってブランチを切ってそれぞれで各チームメイトが作業してね。

⏺ まず、対象のgradleファイルを確認し、git worktreeとチームをセットアップします。

⏺ Searched for 1 pattern (ctrl+o to expand)

⏺ ファイルを確認できました。次にgit worktreeを作成し、チームをセットアップします。

⏺ チームとworktreeが作成されました。次にタスクを作成し、チームメイトを起動します。

⏺ タスクを作成しました。次にチームメイトを並列で起動します。

⏺ 2 agents launched (ctrl+o to expand)
   ├─ @aop-agent
   │  ⎿  Summarize spring-aop.gradle (shift+↑ to manage)
   └─ @context-agent
      ⎿  Summarize spring-context.gradle (shift+↑ to manage)

⏺ 2つのチームメイトを並列で起動しました。それぞれ別のgit worktreeで作業中です:

  - aop-agent: spring-framework-wt-aop worktree (ブランチ: summary/spring-aop)
  - context-agent: spring-framework-wt-context worktree (ブランチ: summary/spring-context)

  完了報告を待っています...


@aop-agent❯ タスク #1 完了 - spring-aop.gradle要約を作成

⏺ aop-agent が完了しました。context-agent の完了を待っています...


@context-agent❯ タスク #2 完了報告

⏺ 両方のチームメイトが完了しました。

*1:https://code.claude.com/docs/en/agent-teams#choose-a-display-mode

*2:https://code.claude.com/docs/en/agent-teams#context-and-communication

*3:https://code.claude.com/docs/en/sub-agents

*4:https://code.claude.com/docs/en/agent-teams#context-and-communication