エージェントを使い続けるためのメタワーク / Meta-work for keeping using the agent

「五反田AI vol.4 - AIを現場で使い続けるための仕組み」の登壇資料です
https://luma.com/nocall-ata0

Transcript

1. 五反田AI vol.4 AIを現場で使い続けるための仕組み エージェントを使い続けるためのメタワーク 人の手が止まる四か所を、仕組みにする r.kagaya（@ry0_kaga） Asterminds株式会社 共同創業者・CTO 2026.10.21
2. はじめに 自己紹介 r.kagaya（@ry0_kaga） Asterminds株式会社 共同創業者・CTO 2022年にログラスへ入社。経営管理SaaSの開発、開発生産性の改善に従事。 生成AI/LLMチームを立ち上げ、新規AIプロダクトの立ち上げを担当。 2025年8月に独立、現職。 翻訳 『AIエンジニアリング』 オライリー・ジャパン 2
3. はじめに AIが働くほど、人の手が足りなくなる。 コードを書く速さは上がった。では、人の仕事はどこへ移ったのか。 3
4. はじめに 今日の話 人の仕事は、AIに任せる仕組みを作り直すメタワークへ移っていく。 SDLCの自動化を標榜するソフトウェアファクトリーも、その典型だと考えている。 はじめに なぜ、人の仕事はメタワークへ移るのか 01 組織のコンテキスト AIが読む知識と、確かめる環境を共有する 02 Autopilot・Ambient AIが自分で動き出し、実装・検証・修正のループを回す 03 Self-improve 使った記録を学びとして蓄積し、自己改善する 04 承認体験の変化 人が変更を理解して、判断できるようにする まとめ 4
5. はじめに AIを並列で何本動かしても、確認する人が一人なら？ ソフトウェアファクトリーが並行してたくさん処理しても、確認と判断は一人に集まる。 詰まっているのは、コードを書く工程ではなく、人が確認して判断する工程かもしれない。 画面の改善 画面の入口の位置をそろえるPR。 自動の判定はGO。マージしてよいですか？ 不具合の修正 本体は直ったが、別の問題が残る。 直すか、直す範囲を決めてください。 速度の改善 約2%の回答で反映に12〜14秒かかる。 どこから手を付けるか、決めてください。 承認待ち NO-GO 判断待ち 一人に、同時に届く 種類の違う判断が三つ。 読むものも違う。 1 判定の結果と、画面のスクショ 2 残った問題と、その影響の範囲 3 遅い回答の割合と、原因の候補 AIを増やすほど、人のところで詰まる。 5
6. はじめに Anthropicの社内調査：AIの出力が増え、人の注意が追いつかない 社内の利用記録・業務データと、社員17人へのインタビューから仕事の変化を調べた。 AIが作る量は増えた。一方で、AIは多くの時間を人の返事待ちに使っていた。 5エンジニア1人あたりの 倍 コミット数（半年前と比べて） Anthropic · How employment is changing at Anthropic · 2026-10-16 www.anthropic.com/research/employment-at-anthropic 約80 % 週の半分超 対話セッションのうち、AIが 非技術職でも、AIの出力を 人の返事を待っていた時間 全部読むのにかかる時間 6
7. はじめに AIを働かせるための仕組みづくりが、増えている Anthropicは、こうした活動を「メタワーク」として分類した。 対話セッションに占める割合は、2025年秋の10%から2026年春の22%へ増えた。 平均的な社員の対話セッションに占める割合 2025年秋 社員が作っていたもの 10% 2026年春 22% 0 5 10 Anthropic · How employment is changing at Anthropic · 2026-10-16 www.anthropic.com/research/employment-at-anthropic 15 20 25% CLAUDE.mdのような指示が、 1年で数百件から8,500件に エージェントからの依頼を トリアージする、秘書役のエージェント AIが問題を見つけて対応まで始める、 採用担当のダッシュボード 7
8. はじめに 自社でも、メインリポジトリのマージ済みPRが1年弱で約14倍に 月50本ほどから月700本ほどへ。2026年9月は、その約4割をDevinが作った。 この量を、人が一本ずつ読んで判断する前提では回せない。 PR数は量の目安。この伸びが生産性をどこまで表すかは、別の議論。 月ごとのマージ済みPR（本）。9月は1か月分の合計 約700 約50 2025/11 12月 2026/1 2月 3月 4月 5月 6月 7月 8月 9月 8
9. はじめに メタワーク＝AIに任せる仕組みを作り、直す仕事 目の前のタスクを片付けるのは、ふつうの実務。 AIが次も同じ質で進められるよう、指示・環境・検査を整えて直していくのがメタワーク。 （例） 起きたこと 実務：その場で片付ける メタワーク：次から起きないようにする 「できました」と言うのに、 自分で起動して確かめ、 画面で動かない 直すよう頼み直す 受け入れ条件を、別のエージェントが ブラウザで確かめてから人に渡す 並列のエージェントから、 確認依頼が何十件も届く 一件ずつ開いて返事をする 自動で進めてよい条件を決め、 判断が要るものだけ人に回す その会話の中で言い直す 会話の記録からつまずきを集め、 手順やスキルの修正PRを作らせる 同じつまずきが、 会話ごとに繰り返される 9
10. はじめに 任せる量を増やすと、人の手が四か所で止まる それぞれの場面で、人が毎回手でやっていることがある。 それを仕組みに置き換えていくのが、今日の四つの章。 01 組織のコンテキスト 02 Autopilot・Ambient 03 Self-improve 04 承認体験の変化 頼むたびに、 前提と仕様を説明する CIが落ちるたびに、 「直して」と頼み直す 同じつまずきに、 毎回その場で対処する 変更が多すぎて、 読み切れず判断できない いま、人が毎回やっていること 仕組みにすると AIが前提を自分で読み、 テストで確かめられる いま、人が毎回やっていること 仕組みにすると AIが自分で動き出し、 直してテストし直す いま、人が毎回やっていること 仕組みにすると 記録から、手順や 道具が直っていく いま、人が毎回やっていること 仕組みにすると 理解して判断しやすい 形で、材料が届く 10
11. 量が増えると、まず前提の説明が詰まる。 組織のコンテキスト 01 頼むたびに、同じ説明をしていないか。 01 組織のコンテキスト 02 Autopilot・Ambient 03 Self-improve 04 承認体験の変化
12. 01 組織のコンテキスト 組織のコンテキスト：説明と準備を、頼むたびにやり直さない AIは、社内で当たり前に共有されている前提を知らない。知らないまま作ると、それらしく間違える。 だから前提を読める形で残し、守れたかを確かめる環境も揃える。 01 組織コンテキスト 02 組織ハーネス ないと ないと あると あると AIが読む知識 社内の前提を知らず、それらしく間違える。 頼むたびに、人が同じ説明をする。 仕様・決定事項・そう決めた理由を、AIが自分で引く。 別の会話や別のAIでも、同じ前提で動ける。 AIが確かめる環境 AIが「できました」と言っても、 守れたかどうかは人が全部確かめる。 作業環境・テスト・取り込みの条件を揃え、 確かめて通ったものだけが人に届く。 12
13. 01 組織のコンテキスト Uber：Software Factoryを支える仕組みの一つ、Context Graph Uberのエージェントは、コードを書くより、情報を探すことにターンを使っていた。 そこで30超の社内システムをつなぎ、どのエージェントからも自然文で引けるようにした。 30超の社内システムをつなぐ 同じ質問・同じモデルで比べた（記事のFigure 10） 「ForgeのVehicle Listを、Hiveで照会する方法はある？」 サービス チーム テーブルの利用履歴 データセット Context Graph PR 2,400万ノード 8,000万エッジ デプロイ 障害記録 53人の分析担当者が使っているテーブルを特定し、 照会の書き方まで示した Context Graphなし 設計書 38秒 正解 Context Graphあり 20分09秒 誤答 サービスのコードを調べ回り、サブエージェント2つ、エラー3回。 最後に「照会できない」と誤答 Uber Engineering · Running a Software Factory Efficiently at Uber Scale · 2026-08-27 www.uber.com/us/en/blog/efficient-software-factory/ 13
14. 01 組織のコンテキスト 自社の組織コンテキスト基盤：Kura（絶賛整備中） 社内の知識・決定事項・イシューを一か所（atlas）に置き、人もAIも同じものを読み書きする。 集める・整理する・聞く、をAIが手伝う。 どのAIからも、CLIで引ける aster-kura search / read / issues Claude CodeもCodexも、同じ知識を読み、イシューを起票する Slackで @kura に聞ける 聞いた人の権限の範囲で、atlasから答える。 記録の追加・変更も、確認ボタンで反映する Slackの会話から、自動で集まる 人は画面で、AIはCLIで、同じドキュメントを開く。 見られる範囲は、その人の権限どおり。 公開チャンネルの決まったこと・方針を、30分ごとにatlasへ格納する AIが毎日、整理する 重なった記録をまとめ、古いものはアーカイブする。 削除は人が承認する 14
15. 知識と環境が揃うと、AIは自分で動き出せる。 Autopilot・Ambient 02 動き出したAIを、どこまで走らせるか。 01 組織のコンテキスト 02 Autopilot・Ambient 03 Self-improve 04 承認体験の変化
16. 02 Autopilot・Ambient Autopilot・Ambient：気づいて頼み直す仕事を減らす 変化をきっかけにAIが動き出し、Verification loopを回して、通るまで直す。 人に聞くところと、止めるところも先に決めておく。 01 Ambient 始める：呼ばれなくても動き出す 02 Autopilot 続ける：通るまで回し、決めた所で止まる きっかけ AIがすること 場面 AIがすること PRが更新された Codexがレビューを書く テスト・画面のQA・判定。 Verification loop NO-GOなら理由を渡して直す CIの失敗・指摘 見回りのAIが直してpushする 仕様の判断が要る 平日の朝6時 ブラウザでQAし、Slackへ報告 マージ・本番の操作 自動では断る PRで担当者に一度だけ聞く 16
17. 02 Autopilot・Ambient ソフトウェアファクトリー：仕事が流れるラインと、それを支える土台 きっかけでAIが動き出し、Verification loopを回しながら、仕事はラインを流れる。 人は仕様の判断と高リスクのPRのマージを受け持ち、流れた記録から手順や道具を直していく。 02 Ambient きっかけ Issue CIの失敗 レビューの指摘 障害の通知 決めた時刻 02 Autopilot 04 承認体験 01 02 03 04 人 Issueを読み、 PRを作る テストと画面で 条件を確かめる 別のAIが見て GOかNO-GO 指摘や競合を 直して待つ 高リスクのPRを 読んで決める 実装 Devin・Claude Code 検証 ブラウザQA 判定 Codex・pr-gate 仕上げ マージする 定期の見回り Verification loop：NO-GO・CIの失敗なら、理由を渡して実装からやり直す 03 Self-improve 低リスクは、条件が揃えば 自動でdevへ 流れた記録（レビュー・判定・失敗・言い直し）から、手順・スキル・道具を直す 01 土台 共有するもの 組織コンテキスト 仕様・決定事項・ 判断の理由・スキル 組織ハーネス 作業環境・道具と権限・ テスト・取り込みの条件 実行の記録 セッション・レビュー・ 判定・失敗の履歴 17
18. 02 Autopilot・Ambient クラウドのエージェントは、時間割どおりに働き続ける クラウドの開発環境（Coder）で、決めた間隔の自動実行を一日中回している。 回し続けると、仕事は自然とファクトリーのラインに沿って流れる。 01 02 03 04 仕上げ 人 夜 平日 6:00 5分おき 30分おき 9:30 実装 検証 Issueから実装し、 PRを作る ブラウザでQAする 判定 マージする Codexが PRをレビューする PRを見回って直す 前日のまとめを読む 10分おき 2時間おき 条件が揃えば PRを1本ずつ 判定する AIのPRを仕上げる 低リスクは 自動でdevへ Verification loop：NO-GO・CIの失敗・指摘は、見回りが拾って直す workspaceは決めた時刻に自動で起動し、その中で時間割が回る。手元のPCを閉じていても止まらない。 18
19. 02 Autopilot・Ambient 確認する人が一人でも回るように、人に届くPRを絞る AIのPRを全部人が同じように読むと、確認待ちが積み上がる。 自社では三つの仕組みで、人に届くPRと、読む手間を絞っている。 01 人を通さない 低リスクで条件が揃えば、 devへ自動でマージ 決まった場所の変更は、 「高リスク」に固定。 それ以外は、AIもリスクを判定する。 CIが成功 指摘なし 競合なし 一つでも欠けたら、人のレビューへ 02 増やさない 確認待ちが上限を超えたら、 AIは新しい仕事を始めない 人のレビュー待ちのPRを数える。 上限を超えたら、新しい仕事より、 今あるPRを先に進める。 CIの失敗を直す 残った指摘に対応 AIは疲れないので、止めないと増え続ける 03 人が読む手間を、 AIがラベルで見積もる 軽重を付ける リスクとは別に、 じっくり読むべきか、 さっと読めば足りるかを付ける。 review: 🔥 heavy review: 🌱 light 読む順番と、かける時間を決める 19
20. 02 Autopilot・Ambient 人に届くPRには、Verification loopの結果が揃っている 高リスクのPRは人に届く。そのとき、AIのレビューと画面での判定が揃っている。 人はこのPRを読んで、マージするかを決める。 ラベル risk: high は規則で付いた高リスク。 factory はエージェントが作ったPR。 Codexのレビュー 「指摘なし。リスク中。GOを待つ。 人の承認1人」と、止める理由まで書く。 pr-gateの判定 PRを起動し、受け入れ条件を画面で確認。 変更前でバグを再現してからGOを出す。 20
21. 02 Autopilot・Ambient Uber AutoClean：人が決めるのは「本当に消してよいか」だけ 使い終わったフィーチャーフラグのコードを、AIが探して消し、CIを直し、検証してから人に回す。 確かめる観点を一つずつ別のAIに任せ、全部通った変更だけが人に届く。 01 見つける 全員に公開し終えた フラグを、管理システム から自動で探す 02 書き換える AIが値を埋め込み、 条件の簡略化は 規則で動くツールに任せる 03 CIを直す 落ちたら直す役に回す。 テストを直す役は、 テストしか触れない 04の中身：観点ごとに、別のAIが確かめる 足していない 消すか簡略化するだけ。コードを足さない 頼まれた範囲だけ 動きを変えていない 外から見た挙動が同じ AIの跡を残さない 関係するほかのフラグに手を出さない 作業中のコメントなどを残さない 一つのAIに全部見させるより、観点ごとに分けたほうが結果がよかった。一つでも落ちたら、人に届く前に捨てる。 Uber Engineering · Using AI to Delete Code: Agentic Tech Debt Cleanup at Uber · 2026-10-20 www.uber.com/us/en/blog/ai-code-cleanup/ 04 検証する 静的な検査のあと、 四つの観点を 別々のAIが確かめる 人に残る判断 「このフラグは、 本当に消してよいか」 機械的な正しさは、 届く前に確かめ終わっている。 数年で、16,000超のフラグ・ 100万行超を削除 21
22. 02 Autopilot・Ambient GitLab：任せる範囲は、検証できた証拠の分だけ広げる GitLabは論文を引き、AIに任せる範囲を4段のはしごで説明する。段は飛ばさない。 下の段で、決めた精度や成功率を満たしたら、一段上がる。 段階 4 段階 3 段階 2 段階 1 すべての手順に 人が関わる 人も関わりつつ 決めた範囲でAIが実行 ふだんは人が関わらず 例外だけ人が担当 最初から最後までAI しきい値で人を呼ぶ 落とし穴：名目上はレビューしていても、物量に押されて全部承認すると、チェックは見かけだけになる。 GitLab · AIエージェントとともにソフトウェアデリバリーを再設計する · 2026-10-21 about.gitlab.com/ja-jp/blog/redesign-how-your-team-ships-software-with-ai-agents/ 22
23. 03 動き出しても、同じつまずきは繰り返される。 Self-improve 同じ失敗を、次の仕事に持ち越さないには。 01 組織のコンテキスト 02 Autopilot・Ambient 03 Self-improve 04 承認体験の変化
24. 03 Self-improve Self-improve：同じつまずきに、毎回その場で対処しない 実行の記録から、次の仕事で使う手順・道具・指示文を直す。 直した後に、同じつまずきが本当に減ったかを比べる。 01 02 03 04 指示・入出力・エラー・ 人のフィードバック 言い直し・拒否・失敗が 多いところを探す 手順・スキル・ 指示文・道具を変える 同じ課題で、前と後の 点数を全部比べる 記録を残す 見つける 直す 比べる 減っていなければ、また記録から探す シンプルな例 エージェントの実行記録をAIに読ませると、「この指示文が曖昧で、毎回同じ確認が起きている」と見つかる。 指示文の変更案を作って入れ替え、次の週に、同じ確認が減ったかを数える。 24
25. 03 Self-improve Factory Signals：つまずきを見つけ、エージェント自身のコードを直す Factory Signalsは、LLMを判定役にしてセッションを分析し、利用者のつまずきを探す。 閾値を超えたら起票し、エージェントのDroidが修正PRを作る。マージは人が承認する。 見つける 「完了した」会話にも、 つまずきが埋もれている 決めておいた兆候 エラー、同じ依頼の言い直し、口調の変化、 利用者によるツール実行の拒否。 3回言い直した人の約4割が、また言い直す。 記録から見つけた、新しい兆候 似たつまずきをまとめ、新しい分類にする。 例：参照ファイルの出し入れ（context churn） Factory · Signals: Toward a Self-Improving Agent · 2026-01-23 factory.com/news/factory-signals ① 起票する つまずきが閾値を超えたら、Linearにチケット ② Droidが直す コードを修正し、自分のPRもレビュー ③ 人が承認する 修正PRを読み、マージするかを決める 直した後に測る 曖昧な依頼への対応を変えると、 言い直しのつまずきが48時間で30%減った 25
26. 04 AIが進められる範囲は広がった。残るのは人の判断。 承認体験の変化 では、人は何が変わったかを分かっているか。 01 組織のコンテキスト 02 Autopilot・Ambient 03 Self-improve 04 承認体験の変化
27. 04 承認体験の変化 承認体験の変化：変更を理解して、判断できるか PRが月700本になると、全部を読んで承認するやり方は形だけになる。 だから人が早く理解して判断できる形で、判断材料を届ける。 いま これから 01 02 変更の背景と仕組み AIが、図つきの解説ページにする 仕事ごとの状況 進み具合と検証結果を一画面に並べる 変更の前と後 人の答え 届いたPRを1本ずつ読み、承認を押す 理解を助ける道具を作る 動きの違いを、表や図で並べる 例：Geoffrey Litt、自社のPR解説 変更を理解し、決めるところだけ決める 判断を返す画面を作る その画面から、承認や追加の依頼を返す 例：Spotify Goose Farm、自社のtatara 27
28. 04 承認体験の変化 人が理解するのは、次に何を作るか考えるためでもある Geoffrey Littは、AIが作るコードを人が理解する意味を、開発への参加から説明する。 検査をAIに任せられても、仕組みを知らなければ次のアイデアを考えにくい。 正しさを確かめるために理解する 仕様に合っているか。設計は妥当か。 受け入れてよいかを判断する。 Geoffrey Litt · Understanding is the new bottleneck · 2026-07-02 www.geoffreylitt.com/2026/07/02/understanding-is-the-new-bottleneck 次の開発に参加するために理解する どう動くかを知り、変更の影響を考える。 その理解から、次に作るものを発想する。 28
29. 04 承認体験の変化 理解の道具を、自社でも作る：PRを図で解説する Littは、コードより先に背景と仕組みを説明し、人が変更を理解できるようにする。 自社でもAIに、PRを図つきの解説ページにさせている。 さっきのPRを、AIが図で解説 最後に、要点を確かめる問題も付ける 29
30. 04 承認体験の変化 判断の仕方も工夫する：前後を見て、チェックを入れるだけ 長いレビュー文を読む代わりに、AIが変更前後の画面を並べ、人は「承認」にチェックを入れる。 チェックした項目だけが、そのままAIへの指示になる。 提案 01 Coderのページ 「何ができるか」を、一日の時間割で見せる これから いま → AIに渡す指示（自動でできる） 次を実装してください（承認済み）： のページを「PCを閉じても 働き続ける」体験に作り直す。 実際の時間割を一日の図にし、 撮影して確認する。 補足：時間割は実際の設定から取る 01. Coder 見送り：04（手を付けない） なぜ：環境の部品の説明だけでは、何が嬉しいか分からない。 ✓ 承認 見送り 補足：時間割は実際の設定から取る コピーして、そのままAIに渡す 30
31. 04 承認体験の変化 Spotifyは、動いているエージェントをガチョウにした 社内のダッシュボードGoose Farmでは、一羽が、稼働中のセッション一つを表す。 裏で働くAIの様子を、農場の風景として一目で見渡せる。 背景で進む仕事を、PRまで追う Honkが背景でコードを書き、 FleetshiftがPRの作成・取り込み・ 対応待ちの状態を追っている。 Spotify Engineering · 2026-06-03 engineering.atspotify.com/2026/6/code-with-claude-coding-is-no-longer-the-constraint 31
32. 04 承認体験の変化 自社では、仕事を庭にしてみた。半分は真面目に （普通の管理画面も、真面目に作っている） でも、承認や確認の体験は、もっと自由でもよさそう。 ふだんは、普通の管理画面 同じ仕事を、庭を歩いて開く 32
33. まとめ まとめ：毎回人がやっている仕事を、一つずつ仕組みにする 01 組織のコンテキスト：前提は、AIが読めて確かめられる形で残す 前提を知らないAIは、それらしく間違える。決まったことを残し、テストで確かめられるようにする。 02 Autopilot・Ambient：進めてよい条件と、止める条件を一緒に作る Verification loopを回し、人に届くPRを絞る。任せる範囲は、検証できた証拠の分だけ広げる。 03 Self-improve：直したら、本当に良くなったかまで比べる 記録からつまずきを見つけて直し、同じ課題で前と後を比べる。 04 承認体験の変化：承認のためだけでなく、次を考えるために理解する AIに変更を図で解説させ、判断はチェックを入れるだけの形にする。 33
34. まとめ AIに任せる仕組みを作るのも、人の仕事。 34