# 人間は今、何をするのか？ AIエージェント時代のソフトウェアエンジニアリングを再考する

- 番組: [AI Engineering Podcast](https://ai-curator.jp/podcasts/shows/cmv8ukqpf00017110ed1v5oja)（Tobias Macey）
- 元のタイトル: What Do Humans Do Now? Rethinking Software Engineering in the Age of AI Agents
- 配信日: 2026年10月16日
- 長さ: 1時間7分
- 要約作成日: 2026年10月16日
- トピック: [#AIエージェント](https://ai-curator.jp/topics/AI%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#コードレビュー](https://ai-curator.jp/topics/%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC) [#静的解析](https://ai-curator.jp/topics/%E9%9D%99%E7%9A%84%E8%A7%A3%E6%9E%90) [#ファジング](https://ai-curator.jp/topics/%E3%83%95%E3%82%A1%E3%82%B8%E3%83%B3%E3%82%B0) [#コーディングエージェント](https://ai-curator.jp/topics/%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#ソフトウェア開発プロセス](https://ai-curator.jp/topics/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9)
- URL: https://ai-curator.jp/podcasts/cmvaa0l7g00002t0znmm5wouc

## 要約

DataStax創業者で、現在はBrokk AI（文字起こし上は「Brock」）を率いるJonathan Ellis氏が、エージェントによるコード生成が桁違いに速くなった今、人間の時間をどこに使うべきかを語った。人間によるコードレビューは欠陥の約3割しか見つけられず、仕様・RFC・アーキテクチャ判断へ人間の関与を前倒しし、静的解析やファジングなどの自動検証（オラクル）に投資すべきだという主張を展開する。BifrostやMjolnirの設計、若手育成、OSSのPR問題、エージェント向け協業ツールの不足にも話が及ぶ。

## ポイント

- エージェントは扱えるタスクの規模が拡大し、並列実行も可能になったため、コード生成が約10倍速くなり、人間中心のプロセスが成り立たなくなっているとEllis氏は述べる。
- 調査では人間のコードレビューが見つける欠陥は約30%（セキュリティ領域では約20%）で、その時間は他の品質保証手段に振り向けるべきだと主張する。
- 人間の価値は実装方法よりも「何を作るか」の判断に移り、全員がプロダクトマネージャー的な役割を担うようになるという見方を示した。
- 静的解析やファジングは新しい技術ではないが、誤検知の仕分けをAIが無料に近いコストで行えるため、初めて実用的になったと語る。
- Bifrostは13言語対応の静的解析ツールで、Gitのblob IDを主キーにすることで、複数のworktreeでも再インデックスを最小限にして数ミリ秒で応答できる。
- 新人育成については「理解している定型作業だけをエージェントに任せ、未知の問題は自分で取り組む」という指針や、説明できて初めて実行する「補助輪」型のハーネスが議論された。

## 章立て

- [00:00] **自己紹介とAIとの関わり** — Ellis氏はDataStax創業やCassandra、JVMでの経歴を紹介し、AIで自分の道具を拡張できる魅力とBrokk立ち上げの動機を語る。
- [03:04] **コード生成の高速化とボトルネックの移動** — タスク規模の拡大と並列化で生成が約10倍速くなり、従来の人間向けプロセスが破綻しつつあると議論する。
- [05:19] **レビューを仕様・設計へ前倒しする** — コードのイディオムへのこだわりを手放し、RFCやADRなど設計段階に人間の判断を集中させる考えを述べる。
- [12:53] **コードレビューの有効性と代替策** — 人間のレビューが欠陥の約30%しか見つけないという調査を根拠に、品質ゲートや検証ループへの投資を論じる。
- [19:29] **Bifrostとオラクルによる検証** — Coverity的な高速静的解析をエージェントに提供し、ファジングなどのオラクルで誤検知を仕分けする手法を説明する。
- [25:16] **スキル文書・ADR・メモリ管理** — 若手育成やエージェントのオンボーディングのため、スキルやexec plan、グラフ型メモリなどの知識の残し方を議論する。
- [39:44] **自作の誘惑とOSSのPR問題** — 自前で作る罠と、メンテナの「断る」仕事の重要性、BifrostでPRを閉じた判断を語る。
- [48:48] **人間の役割・新人育成・今後の課題** — 人間の目標設定の役割、MjolnirやBifrostの設計、ベンチマークの飽和、エージェント向け協業ツールの不足を話す。

## 解説記事

DataStax創業者で現在はBrokk AI（文字起こし上の表記は「Brock」）を率いるJonathan Ellis氏が、AI Engineering PodcastのTobias Macey氏と、エージェントがソフトウェアを作る時代に人間の時間をどう使うべきかを議論した回である。中心となるのは「人間によるコードレビューはもはや良い時間の使い方ではない」という大胆な主張だ。

#### ボトルネックの移動とレビューの再考

Ellis氏によれば、AIの効果は当初「コード作成が50%速くなる」程度で、既存のチームやプロセスにそのまま組み込めた。しかし今は、モデルの出力速度ではなく、一度に任せられるタスクの規模が拡大した。同氏は十数個のタスクを並列に走らせ、それぞれが数時間から数日かかると述べる。監視を減らして並列化できるため、生成速度は約10倍になり、人間向けのツールやプロセスを使い続ける前提が崩れたという。

同氏は、diffを読むレビューが最初に不要になる習慣の一つだと見ている。Macey氏も、自分の書き方と違うから悪いというイディオム論争は、人間のチームでも生産的ではなかったと指摘した。人間のチームを率いた経験がある人ほど、この切り替えに順応しやすいという見方も共有された。

#### 「レビューは欠陥の約3割しか拾わない」

Ellis氏がこの主張で根拠として挙げるのは、人間のコードレビューが見つける欠陥は一般に約30%、セキュリティのような難しい領域では約20%という調査結果だ。人間は欠陥を見つけた成功体験ばかりを覚えており、見つからなかった多数のレビューを統計的に評価するのが苦手だと説明する。同氏はレビューに価値がないと言うのではなく、その時間を使うならもっと効果の高い手段があるという立場だ。社内向けツールなら読まずに出荷して問題が出たら直す、というMacey氏の実践も紹介されたが、Ellis氏はそれは容易なケースで、本当に難しいのは不具合が重大な結果を招く場面だと述べた。

#### 検証にこそ投資する：Bifrostとオラクル

BrokkのBifrostは、Coverityのような静的解析をエージェントのハーネスに組み込むツールである。use-after-freeや並行処理のデッドロックなどを、CIで数時間待つのではなく、エージェントのツール呼び出しでミリ秒単位に確認できることを目指す。13言語を同時に扱うため、正しさの保証が難しい。そこで同氏が重視するのが「オラクル」、つまりある種の問題で正解を知っている仕組みを作り、エージェントにその構築も任せる考え方だ。ファジングやプロパティテストなど、ここで使う技術自体は新しくない。新しいのは、SonarQubeやCoverityなどの解析結果に付きものだった大量の誤検知を、モデルに仕分けさせて修正チケットにできるようになった点だという。「レビューも実質無料になった」と同氏は述べている。

技術的には、Bifrostのデータベースの主キーにGitのblob IDを使い、複数のworktreeで作業しても未知の内容だけを再インデックスすれば済むようにしている。これで新しいworktreeのインデックス作成が即時になり、セッション中に並行処理の問題がないかを問い合わせられる。

#### 知識の残し方と若手の育成

同氏はAIエージェントを「毎日が初出勤日の優秀な新人」にたとえた。そのため、決定事項、行き止まりになった試み、目標を文書にして残すことが重要になる。OpenAIが紹介したexec plan（長時間タスクの計画文書）は、今ではタスク継続の目的では不要になったが、後から「なぜこうしたか」を調べる記録として有効だという。コード内のコメントはgrepでは見落とされやすいため、計画文書の置き場を示すほうがエージェントに合う。Macey氏は、自作のグラフ型メモリ（OmniGraph、Lance使用）を紹介し、Ellis氏はVectorizeのHindsightを勧めた。

若手の育成について、Ellis氏は決定的な解はないとしつつ、自分の子どもには「理解している定型作業はエージェントに任せてよいが、未知の問題を丸投げしてはいけない」と伝えていると語る。Macey氏は、問題を十分説明できて初めて実行する「補助輪」型のハーネスを提案した。Ellis氏は、チェスで機械が人間を超えた後も人が競い続けている例を挙げ、人間がやる意味は残るという見方を示した。

#### 自作の誘惑、OSS、そして残る課題

両者は、エージェントのおかげで何でも自作できるが、保守や機能要望対応という氷山の水面下を見落としがちだと指摘した。OSSでも、エージェント製のPRが大量に届き、メンテナが疲弊する問題がある。Ellis氏はBifrostのリポジトリでPRを無効化してIssueのみ受け付け、自分のエージェントで対応している。1980年代のFSFが外部パッチを受け付けなかった例を引き、共有ソース型への回帰を予想している。

Mjolnirは、Codex、Claude Code、Kimi Codeなどを一つの画面で扱うメタハーネスで、ACPというプロトコルでこれらを駆動する。サブエージェント用の仮想ワークスペースを追加し、高価なモデルが安価なモデルを動かすことで契約枠を最適化している。一方でAnvil（独自ハーネス）は、大手ラボの統合の深さに太刀打ちできないとして優先度を下げた。課題としては、モデルが会話全体を毎回クローンするような非効率な実装をする「ギザギザの限界」が残る点、そしてSWE-benchやDeepSWEなどのベンチマークが飽和して役に立たなくなっている点を挙げ、実際のBifrostチケットでモデル同士を比較する計画を述べた。

#### まとめ

本エピソードの核心は、人間の注意を「コードを読む」から「何を作るか決める」「検証の仕組みを作る」へ移すべきだという主張である。レビューを完全に廃止すべきかどうかは意見が分かれるだろうが、欠陥検出率の低さを踏まえ、仕様・設計段階の合意と自動検証への投資を増やすという方向性は、日本のチームにも参考になる。また、最大のギャップとして語られた、エージェントを前提にした協業ツール（チケットから過去のセッションを復元して回帰を直させる仕組みなど）は、今後のツール開発の注目点となりそうだ。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: AI Engineering Podcast「What Do Humans Do Now? Rethinking Software Engineering in the Age of AI Agents」