#グラレコ
はじめに
AI駆動開発カンファレンス 2026夏の1日目、2026年7月30日に参加し、6つのセッションを聴講してきました。公式ハッシュタグは #aiddcon2026 です。
登壇の顔ぶれが今年らしくて、Devin を作っている Cognition のキーノートから始まり、人月モデルの崩壊とジュニア育成を語る ULS、国内金融機関としてフルスタックのAI駆動開発プロセスを構築中のみずほ証券、Claude Code で「第二の脳」を自作した個人開発者、ガバナンスを設計する LINEヤフー、そして品質文化の重みを背負う大規模製造業のダイキン工業。ベンダー・エンタープライズ・個人・製造業と立場がまったく違うのに、終わってみると全員が同じ場所に着地していました。
その場所とは「安心して任せる仕組み（ハーネス）をどう作るか」です。この記事では6セッションを講演の流れに沿ってできるだけ細かく整理し、最後に共通テーマとしてその重なりをまとめます。長い記事ですが、AI駆動開発を組織で進める立場の方にも、個人で試している方にも、持ち帰れる具体が多い一日でした。
💡 本記事は筆者個人の聴講メモに基づくレポートです。講演の全内容を網羅・正確に再現するものではなく、講演中の数値はスライドからのメモで独自検証はしていません。文責はすべて筆者にあります。
1日目の全体像 🗓️
聴講したセッションのタイムテーブルです。
| 時間 | セッション | 登壇者 |
|---|---|---|
| 11:00–11:50 | Opening Keynote「コーディングの終わりと、ソフトウェア開発の始まり」 | 正井 拓己氏 / シバタ アキラ氏（Cognition AI Japan） |
| 12:10–12:50 | Lunch Session「人月モデルの崩壊とこれからの人材育成」 | 漆原 茂氏（ULSコンサルティング） |
| 13:00–13:40 | Special Speaker「みずほ証券スタイルのAI駆動開発」 | 杉谷 剛氏（みずほ証券） |
| 15:00–15:40 | 「『寝てても仕事が進む』Claude Codeで組む第二の脳」 | 藤田 智也氏（Grizzlarity） |
| 15:50–16:30 | 「AI開発におけるガバナンス」 | 新田 祐介氏（LINEヤフー） |
| 16:40–17:20 | 「大規模製造業でのAI駆動開発との向き合い方」 | 前川 博志氏（ダイキン工業） |
先に見取り図を示すと、この6本は「①ハーネスで安心を作る」「②可逆性×検証可能性で線を引く」「③良しの定義と人材育成は人間の仕事」の3テーマで貫かれていました。順番に見ていきます。
セッション1：コーディングの終わりと、ソフトウェア開発の始まり 🚀
（正井 拓己氏 / シバタ アキラ氏／Cognition AI Japan）
Devin を開発する Cognition のキーノートです。「the first AI software engineer」として2024年3月に X で発表された Devin が、いまどこにいるのかという現在地報告から始まりました。
Devin の現在地：伸びの主因はイベント駆動
週次セッション数は2026年に入ってから10倍超。2025年初は横ばいだったカーブが、2026年1月以降に急上昇しています。興味深いのは伸びの主因で、人間がお願いする分ではなく「イベント駆動型のセッション」だそうです。Snyk / SonarQube / Datadog / PagerDuty といった検知系ツールからの自動起動分が積み上がっている、と。人が打鍵する回数ではなく、システムが検知した回数がエージェントの稼働量を決める世界に入りつつあるわけです。
ローカルAIエージェント → クラウドAIエージェント
セッションのメインテーゼがこれです。
この図のポイントは、右側の特徴が全部「組織」の言葉になっている点です。一度組織レベルで設定すれば、すべてのユーザーがセットアップなしで社内ナレッジを共有でき、Slack のスレッドからどこでもタスクを依頼できる。JIRA などのプロジェクト管理ツールからも同様に呼び出せて、アウトプットはコードだけでなくテスト結果の動画まで返ってくる。実行環境は Hosted（Ubuntu / Windows）と Outposts（自前マシン）から選べて、モデルは「Fusion」を選択する構成でした。
コード生成は SDLC のごく一部
ここが刺さった指摘です。エンジニアリングワークフローの中でコード生成が占める割合は20%未満。ローカルAIエージェントが効いているのはこの一部分だけで、残りの8割（調査・レビュー・テスト・運用など）に効かせるのが非同期クラウドエージェントの狙いだ、と。「AIで開発が速くなった」の実感が伸び悩む理由の説明としても納得感があります。
品質面の裏付けとして、AIコードレビューを専門とする Greptile が2026年5月に GitHub 上のデータを広範囲に精査した調査が引かれました。セキュリティ脆弱性・コード内のバグ・コード管理の質について4つのAI製品（Claude / Codex / Devin / Cursor BG）で問題が起こる頻度を比較したもので、評価軸は1が人間基準・数字が小さいほど優秀。比較項目が具体的で、SECURITY（SQLインジェクション / XSS / auth bypass / IDOR・テナントチェック漏れ / ログへのsecret混入）、CORRECTNESS（N+1クエリ / 既存機能のリグレッション / off-by-one / タイムゾーン・日付バグ / 環境変数・設定バグ）、MAINTAINABILITY（テスト欠落 / デッドコード / 古いコメント・誤ったドキュメント）と並びます。Devin はほとんどのカテゴリで好成績、という結果でした。
Cognition 自身のドッグフーディング
数字が強烈でした。Cognition のコードのうち Devin がコミットした割合の推移です。
| 時期 | Devin のコミット比率 |
|---|---|
| 2025/12 | 13% |
| 2026/1 | 17% |
| 2026/2 | 33% |
| 2026/3 | 76% |
| 2026/4 | 83% |
| 2026/5 | 89% |
半年で13%から9割へ。しかも基盤モデルの進歩だけでなく、ハーネスエンジニアリングで実現した特化型エージェント群の協調によって PR マージ率が1年前の40%から80%へ向上した、と説明されました。製品開発の生産性（Merged PR volume）は 2025/11 を1x として 12月2x → 1月3x → 2月5.3x → 3月7.7x → 2026/4 で 10.0x。一方で R&D のエンジニア人数は1.4x しか増えていません。
基盤モデルの「ユースケース飽和」は近い
Frontend Code Arena のスコア推移が示されました。米国勢は Claude-3.5 Sonnet 1,206 から Claude Opus 4.7 1,583 / Claude Fable 5 1,631 まで伸びる一方、中国勢も DeepSeek-V3 953 から GLM-5.2 (Max) 1,595 / Kimi-K3 1,679 まで追い上げ、上位で交差しています。結論は「ほとんどの日常的な開発タスクでは、どのモデルも十分賢い状態になる」。競争の軸は「モデルの賢さ」から「そのモデルをどう使いこなす仕組み」へ移り、賢さがコモディティ化する世界で差がつくのは"使い方"の設計力だ、と。
その具体が Devin Fusion（モデル・ルーティング層）です。タスク（プロンプト・コード・画像）をルーターが受け取り、推論・計画／コーディング／長文・画像／軽量・高速という軸で GPT（OpenAI）／Claude（Anthropic）／Gemini（Google）／SWE（Cognition）へ振り分けます。マルチモデルのルーティングによって、同じパフォーマンスを35%コストエフェクティブに提供（Frontier performance at 35% lower cost）。FrontierCode Extended Benchmark のスコアとタスク当たり平均コストがこう並びました。
| 構成 | 平均コスト / スコア |
|---|---|
| Fusion + Fable 5 | $3.00 / 57.6 |
| Fable 5 (medium) | $5.12 / 57.0 |
| Opus 4.8 (high) | $3.24 / 48.8 |
| Fusion | $2.38 / 47.9 |
| GPT-5.5 (high) | $3.64 / 44.8 |
| GLM-5.2 | $2.70 / 43.0 |
内部構造は Main Agent と Sidekick の分業で、Main Agent が計画・コードレビュー・修正依頼を担い、Sidekick がコード探索・コード/テスト記述・lint 修正などを引き受けます。以前この記事シリーズで扱った「オーケストレーター/ワーカー分業」が、製品として実装されている形です。
コーディングの終わりと、役割の格上げ
タイトルの由来は CEO Scott Wu の言葉でした。「私たちは、そう遠くない将来、コードそのものを直接扱うことはなくなるでしょう。しかし、変わらず重要なのは、Devin は人間がコンピュータに『何をしてほしいか』を伝えるためのインターフェースだということです。そもそもソフトウェアエンジニアリングとは、そのために存在していたのですから」。動画字幕は "WE'RE NOT GOING TO BE INTERACTING WITH CODE"。
社会的な文脈として、日経新聞 2026/7/20「エンジニア賃金、二極化 — コード生成など5割安、AI代替で雇用縮小」が引用されました。2022年以降、AIに代替されにくい仕事は単価が2割上昇、自動化が進む下流工程は5割下落（レバテック調べ、2022年4月=100の指数）。プロジェクトマネージャーは上昇、HTMLコーダーは大きく下落。講演の解釈は前向きで、これまで開発はエンジニアの専有物だったが、意図を言語化できる人＝ビジネス側も開発の起点になれる。エンジニアの価値は、曖昧な要求を検証可能なスペックに翻訳し、エージェント艦隊を設計・監督する「判断力」へ移る。これは職種の消滅ではなく、一人が扱える仕事のレバレッジが桁違いに上がる「役割の格上げ」だ、と。
SRE ユースケースと、非同期/対話の3軸判定
実用例として SRE が挙げられました。インシデントのモニタリングチャネルに常駐し、エラーの一次調査を即座に開始する。同じエラーが複数回起こっても前回調査済みならセッションは起動しない。デモでは Slack に流れた UnboundLocalError: cannot access local variable 'backoff_time' を受けて Devin が調査を始め、main.py:182-202 で SwitchBot API が429を返した際に using_global_creds=False（ユーザー固有の認証情報）だと backoff_time の計算がスキップされるのに後段で無条件参照している、と原因を特定。修正方針（計算を if の外に移す／デフォルト値を設定）を提示して PR 作成まで提案していました。SRE ユースケースは「検知・トリアージ → 調査・原因特定 → 改善・キャパシティ → ドキュメント・ナレッジ」の4段階で整理されました。
そしてこのセッションで一番実務に持ち帰りやすかったのが、非同期エージェントと対話型AIの使い分けを判定する3軸です。グリーンフィールド／ブラウンフィールドの分類では見えない適正を、次の3つで見ます。
3軸がそろう仕事の例として、仕様の明確な新規開発（受け入れ条件とテストを書けば0→1でも委譲できる）、言語・フレームワークの一括マイグレーション（既存テストが正解を定義し、スライスに割れる）、機械的リファクタ／依存更新・脆弱性対応（挙動不変が受け入れ条件、差分が小さく可逆）、テスト追加・カバレッジ拡大（本番コードに触れず、対象ファイル数だけ量がある）、バグのトリアージとチケット消化、本番エラーの一次調査と修正PR提案（スコープを提案までに切れば C が可逆になる）が挙がりました。
逆に対話型AI＋人間に向くのは、軸が欠ける仕事です。探索的なプロトタイピング（A・B が欠ける：作りながら仕様を発見する）、原因の見当がつかない深いデバッグ（A）、UI・体験・ブランド表現（A：「良い」の基準が人間の中にしかない）、アーキテクチャ・技術方針の決定（A・C：トレードオフの判断そのものが成果物）、本番データなど不可逆な操作（C）、未知技術の学習（B：委譲のオーバーヘッドの方が大きい）。
さらに秀逸だったのが「軸が欠けているときの処方箋」です。
| 欠けている軸 | 処方箋 |
|---|---|
| A 検証可能性がない | 検証手段を作る作業自体を先に委譲する（テスト追加はマージ率67.1%の主力用途。土台ができれば本題も委譲できる）／受け入れ条件を先に文章化して確定させる／UIは仕様＋スクリーンショット・録画で機械検証に寄せる |
| B 量・反復性がない | 「まだ1件しか見えていない」を疑う（バックログ・CI失敗履歴・エラーログを横断して束にする）／独立スライスに分割して量を人工的に作る／それでも単発なら委譲しない |
| C 失敗コストが高い | 渡すスコープを可逆な範囲に切る（調査・提案・ドラフトPRまで）／チェックポイント報告を指示に明記／隔離環境と段階的ロールアウトを前提に分割 |
原則として「A・B・C はタスクの固定属性ではなく、渡し方（スコープの切り方・分割の仕方）と環境整備で動かせるレバー」と示されたのが、この整理の一番いいところだと思います。「このタスクは任せられない」で終わらせず、どの軸を作りに行くかの議論に変えられます。あわせて組織側の前提条件（CI・テスト資産／Knowledge・Playbook／レビュー体制／起動の自動化余地）も別テーブルで示されました。
告知として、DevinCon Tokyo が2026/8/26に浜松町コンベンションホールで開催されるとのことでした（マイグレーション・レガシーモダナイゼーション、AI駆動型開発組織、SRE・運用、内製開発への移行の4トラック構成）。
セッション2：人月モデルの崩壊とこれからの人材育成 👥
（漆原 茂氏／ULSコンサルティング）
自己紹介スライドのタイトルが「毎晩コード書いて寝落ちする♥」から始まる、熱量の高いランチセッションでした。漆原氏は ULS Consulting 取締役会長／ULS GROUP 代表取締役会長で、AI駆動開発コンソーシアム 設立発起人・副座長、Generative AI Japan 設立発起理事。プロフィールを JSON 風に表現するスライドで、趣味に大規模分散・高速処理・生成AI・NHKスペシャル・ブラタモリ・ライブ推し活・数学（e^iπ+1=0）・素数・偏微分方程式が並び、得技が「円周率 読経」という掴みでした。
大規模システム開発は「大量の人員を投入、管理する」産業だった
前半は構造の話です。発注元の複数チームの下にコンサル会社・SIer が8社ほど横並びで入り、その下に一次請け→二次請け→三次請け→派遣・SES が多段に連なるピラミッド。最下層で DB・ミドルウェア・サーバー・ストレージ・ネットワーク・セキュリティ・クラウド・監視運用・バックアップ・データセンターの各ベンダーに接続する、極端に複雑な網目構造が示されました。
そこで暗黙に起きがちな対立構造が、3者の視点で整理されました。
| 立場 | 課題（抜粋） |
|---|---|
| 発注側（顧客） | 期間・人数に比例した費用（生産性が向上しても費用が下がりにくい）／ブラックボックス化／ベンダーロックイン／価格の不透明さ／品質責任が見えにくい／技術力が見えない（「何人投入したか」は見えるが「誰がどれだけ価値を出したか」は見えない）／内製化が進みにくい |
| 受注側（SIer・ベンダー） | 売上が人数×期間に依存／スキル差が単価に反映されにくい／下請け依存が進む／ノウハウが資産化しにくい／価値ではなく人月単価で比較される／成果ではなく稼働が評価されリスクを取りにくい |
| 双方に共通 | 価値ではなく投入工数が中心／生産性向上が利益につながりにくい／AIや自動化の効果を契約に反映しづらい／「人数を管理するプロジェクト」になりやすい |
AI は「開発体制」と「価格の決まり方」を抜本的に変える
セッションの主張がここです。
価値の移動も明示されました。従来側にあったのは人月／工数／契約／仕様書／コード。AI時代側に移るのは課題設定／意思決定／業務理解／アーキテクチャ／品質／チーム。「ヒトしかできないことの価値が上がる」として、内製開発の促進／少人数でも良いチーム／知識資産・ノウハウ／透明性・信頼関係の4本柱が提示されました。
エンジニアの雇用と、ジュニア育成論
雇用についての見立ては冷静でした。最近の削減はコロナ期の過剰採用の反動調整であり、むしろ拡大している。削減が顕著なのは管理部門・採用部門・低採算プロジェクトで、AIなどの重点領域へ資源移動が起きている。ただし若手・初級職のエンジニア採用は弱まっている。各社の従業員数推移（Alphabet 190,234人→約19.1万人、Meta 86,482人→約7.9万人、Apple 約164,000人→約166,000人、Amazon 1,541,000人→約157.6万人）を示しながら、大規模削減後にほぼ回復・再増加している実態を確認していました。
ここからが本題です。「ジュニアエンジニアはいらない？」への回答が「私たちは皆、かつてはジュニアエンジニアだった！」。ジュニアは「将来の熟練者が必ず通る成長過程」であって能力が低い人材ではなく、若手の道を閉ざすことは将来のシニアがいなくなるのと同じ、と。各社の姿勢も並べられました（NVIDIA: 若手人材は将来のリーダー／Microsoft: 実務と教育を組み合わせた Leap／LinkedIn: REACH の技術見習い制度／GitHub: ジュニア成長にはチームとメンターが必要／Stripe: AI時代でも明確に新卒採用／ULS: 絶対に新卒採用して育てる）。
そして「かつて私たちはこうして育ってきた」として、小さな実装・手作業でのコーディング／デバッグとコードレビュー／障害対応・運用保守／リファクタリング・追加開発／設計上の失敗とリトライ／顧客との難しい調整／本番環境での修羅場、が挙がります。これをコルブの経験学習モデルに重ねたのが本セッションの核心でした。
この図のポイントは、AIに丸投げすると①と②が失われ、③④のステップに×が付く——つまりループそのものが回らなくなるという指摘です。裏付けとして研究が3本引かれました。CHI'25 の "The Impact of Generative AI on Critical Thinking"（Hao-Ping Lee / CMU、Microsoft Research ほか。AIを信じると批判的思考力が低下する）、PNAS の "Generative AI without guardrails can harm learning: Evidence from high school mathematics"（答えを簡単に教えるAIは学習を阻害する）、そして ACM Opinion "Redefining the Software Engineering Profession for AI"（Mark Russinovich & Scott Hanselman）の「早期キャリアの開発者を採用しなければ、この職業のタレントパイプラインは崩壊し、組織は次世代の経験あるエンジニアがいない未来に直面する」。
育成方法は、AIを使いつつ人間側に思考・判断・検証の経験を残す設計として整理されました。まず自らの考えを出させる（要件・タスク分解・設計案・リスク・テスト方針・仮説や不明点）。AIの結果をレビューさせ、誤りを発見して修正させる。そして「意思決定」を早い段階から「実環境で」体験させる（要件定義、設計レビュー、優先順位決定、顧客Mtg、障害対応、リリース判断、セキュリティレビュー、振り返り）。あわせてビジネス・デザイナー・エンジニア・QA・データ分析が1チームで並走してモブ的にナレッジを蓄積する形（目的・背景／なぜそうしたか／なぜこの設計か／どう実装したか／学び・気づき）も示されました。
これからのシステム開発の形として、スモールチーム＋AIエージェント／完全請負（品質保証・責任を取る）／定額モデル・生産力提供／成果報酬（価値シェア）の組み合わせが提案され、「エンジニアが大きく貢献できる時代が到来。AIツールは誰でも使える。人とチームを育て続ける企業が競争力を持つ！」で締めくくられました。
セッション3：みずほ証券スタイルのAI駆動開発 🏦
（杉谷 剛氏／みずほ証券）
エンタープライズ、しかも規制の厳しい金融機関の実践報告です。冒頭で「AI駆動開発カンファレンス 2025秋は聴講者として参加、2026夏は登壇者として参加」という STEP UP の流れを示すのが洒落ていました。「事業会社におけるエンタープライズ開発という観点でお話しします」と立ち位置を明示してのスタートです。
なぜAI駆動開発プロセスの構築が必要なのか
経営層からは生産性向上・コスト削減、ビジネス部門からはスピードアップという要請。しかし key point として挙げられたのは IT の現場での必要性でした。業務量増加 × 人材確保難 ＝「業務と人材のスタグフレーション」。少子高齢化でこの傾向はますます顕著になる。加えてAIを活用しない場合のリスク（フロンティアAIの脅威）も増大する。結論は「開発生産性の向上に留まらず、開発プロセス自体を『人とAIの協働型』に変革することが必要」。
前提として「AI駆動開発のスタイルに唯一の正解は無い」と明言されたのも良かったです。旧来型の大企業がスタートアップと同じことをしようとしても無理。規制の厳しい業種とそうでない業種では判断基準が異なる。内製化率が高い企業と外部委託依存度が高い企業では社員のスキル特性が異なる。「みずほ証券スタイルを1つの取り組み事例として、各社に適したAI駆動開発の参考にしてほしい」というスタンスです。
変遷：Copilot 元年からフルスタックへ
「担当者主体プロセス」と「AI主体プロセス」の2レイヤーで、要件定義→基本設計→詳細設計→開発→単体テスト→結合テスト→SIT→UAT→リリースの全工程をマッピングした図が分かりやすかったです。
この図のポイントは、「Devin と出会って1年後には、システム開発の全工程をカバーするフルスタックのAI駆動開発プロセスを構築」というスピード感です。しかも単一ツールではなく、工程ごとに適したツールを組み合わせ、ナレッジコンテキストを保持する Snowflake を MCP で繋ぐエコシステム方式。
発想の切り替え：PoC の考え方
ここが個人的に一番の学びでした。PoC についてのポイントが3つ示されます。
- 何を目指しているのか: 生産性の向上自体は目的ではなく手段。目的はあくまでも、開発プロセス自体を『人とAIの協働型』に変革すること
- PoC で見極めるべきこと: 生産性向上効果の可視化に労力をかけるのではなく、そのAIを利用できない要因（ノックアウトファクター）が無いことを見極める。生産性向上効果は後からついて来る。「例えば、コンサルタントに委託して3ヶ月〜半年の効果評価を行うのであれば、そのコストでコーディングAIを1年間利用することが出来る」
- PoC の進め方: 領域でもシステムでもなく『人』を選抜して進める
2番目の指摘は痛快です。効果測定に半年かけるより、その予算で1年使ってしまえ、と。そして測るべきは「効果があるか」ではなく「使えない理由がないか」。エンタープライズで新技術を通すときの現実的な作戦として、そのまま真似できる考え方だと思います。
土台づくりと、推進体制
一足飛びにAI駆動開発プロセスを構築したのではなく、生産性向上施策のその先にAI駆動開発があった、という順序も強調されました。2023年度から UIテスト自動化（Ranorex、2025年度に定常化）、2024年度からアーキテクチャ標準化・開発標準策定、コンテナ（Podman/ECS）・クラウド（AWS）活用促進。リポジトリ更改は2024年度に CodeCommit で CLOSE、2025年度に GitHub Cloud へ移り CI/CD（GitHub Actions）を導入。この過程で「SaaS を安全に利用するためのセキュリティ対策」を実施し、その上に GitHub Copilot と Devin が乗っています。
推進体制では、CoE チーム（IT業務変革推進チーム）の形態比較が実務的でした。バーチャルチーム（仮想組織）はメリットが現場感覚の維持・コストとリスクの低減、デメリットが優先順位の競合・スピード感の欠如。フィジカルチーム（専任・常駐組織）はメリットが圧倒的な推進・専門性の深化、デメリットが現場との乖離・戻り先の確保。成功ポイントは「フィジカルとバーチャルのハイブリッド型で推進チームを組成すること」。
そして二人三脚での牽引です。全体統括（トップダウン）がビジョン/戦略/ロードマップの策定と意思決定を担い、CoE チーム（推進）が施策の立案/推進・実装/実践・伴走支援を担う。製品選定は両者にまたがる。「全体統括は現場任せにしない」「ボトムアップは開発現場での施策実践で、支えるのは自分達の仕事を変えていくことへの主体性」。狙いは「変革への Agility, Capability 向上」でした。
クロージングでは、話せなかったこととして「エコシステム方式でフルスタックを構築することの戦略性」を挙げ、「何を使うか？ではなく、どう使うか？が重要」と一言。今後の重要ポイントは、AIとの協働・内製化、人材育成とIT部門の組織開発／AI駆動型ITガバナンスの構築（この2つを「AIファースト」として括り「AI駆動経営的なIT組織の運営」へ）、そしてAI駆動開発 × サイバーセキュリティ対策、と締められました。
セッション4：「寝てても仕事が進む」Claude Code で組む第二の脳 🧠
（藤田 智也氏／Grizzlarity）
全91スライドの濃密なセッションでした。藤田氏は業界特化型AIプラットフォーム「KumaKumaAI」を開発・提供する Grizzlarity の CEO。Neovim lover / tmux lover で、$ uvx t-fujita を叩くと自己紹介が出るという掴みから始まりました。普段の作業画面（kitty のタブが接続先ごと、Claude Code をペイン分割して並列実行、tmux セッションは開発環境ごとに何枚も）を見せるところからして、地に足のついた話でした。
Claude Code の3つの機能
構成の土台になっている機能が3つ紹介されました。スラッシュコマンドは .claude/commands/ にマークダウンを置くと /コマンド名 で呼べるもので、「書いてあるのはコードでも設定ファイルでもなく手順書」。実物 morning-brief.md の冒頭は「1. date で現在日時を確認する（環境の日付は信頼しない）2. 今日の予定を取得する 3. 各予定の事前準備を作る。people/ business/ projects/ から文脈を集める」。いま15本あり、cron が叩くのは claude -p "/morning-brief"。「仕事に名前をつけて、置いておくだけ」という表現が良かったです。
スキルは .claude/skills/ に置くと description を見て必要なときだけ自動で読み込まれる仕組み。手順を全部 CLAUDE.md に書くと毎回読まれて重くなるので、使うときだけ読ませたいものをこちらに置く。許可の出し方は主に3通りで、--allowedTools（事前承認リスト）、--permission-mode auto（書いていない操作は分類器が判断）、--disallowedTools（書いた操作は必ず止まる。分類器より先に評価される）。ここで刺さった一言が「auto は『止まらない』ための設定です。『制限する』ための設定ではありません」。だから無人運転では、メール送信・PRのマージ/クローズ・削除・force push などを --disallowedTools に並べる。「止めたいものだけを並べれば済む」わけです。
第二の脳を作った背景と、その中身
「第二の脳」は Notion / Obsidian / NotebookLM / Tana を土台に組むのが一般的で、発表者も Markdown を AI に読ませるところまでは同じだったそうです。自分で作った理由は「自社製品の開発／受託でのエージェント開発／営業／顧客対応が並行していて、手が足りないというより脳みその切り替えコストで一日が溶ける」。こぼれるのはいつも同じ場所（相手の返事待ち／締切／記録し忘れ）で、忙しいと尚更ミスる。そこで Claude Code を「社員として扱う」ことにした、と。
冒頭のデモが強烈でした。起きる前に生成されて Slack に届いていた通知——「講演資料の提出が2日超過。Gmail を確認したが提出確認メールなし。今日の日中は予定が空いているので、最優先で今すぐ着手を」。続いてテーブルクロス・名刺の手配が1日超過、T社の返信待ちが8日経過（催促メールの下書きを作りますか）、同期ジョブの最終同期が約61時間前で18時間の基準を大幅超過。そして「1件目。これ、いま映してる資料のことです」。会場が沸いたポイントです。
実体は、ただの git リポジトリでした。Markdown と git だけで、DB もフレームワークもフロントエンドもない。
この図のポイントは「ディレクトリ構成がそのままスキーマ」だという点です。型定義を書く代わりにディレクトリで切る。daily/ はその日の記録（タスクは書かない）、tasks.md は未完了タスクの唯一の正本、questions/ は承認待ちチケット。「置き場所そのものが、そのファイルの意味です」。
実績は2026-07-29時点の実測で 50日で662コミット／47スクリプト／15定期ジョブ。1日あたり13コミットで、その3分の1は寝ている間に積まれているそうです。
DB を使わなかった3つの理由も明快でした。①grep で串刺しできる（grep -rn '@waiting' . だけで相手にボールがある案件が全部出る）②10年後も読める（ベンダーロックインがゼロ）③git diff で追える（AIが何をしたか行単位で分かる。差分で追えないと任せたあとのレビューができない。「これが一番効いています」）。
構成は母艦（Ubuntu、自分が触る対話セッション専用、cron ゼロ）と Raspberry Pi（常時稼働、誰も触らない、cron 15ジョブと Slack ゲートウェイ常駐）の2台分離。同期は GitHub のプライベートリポジトリ経由で「特別なプロトコルは無い。同期は git」。余談として、常時稼働なら microSD より SSD（この Pi の実測は1日2.2GB・年815GB）という現場知も共有されました。
できること：観測と実行を分ける
機能は5つ紹介されました。①朝の「今日の提案」（tasks.md・カレンダー・直近の daily/ を読む → 期限超過と滞留を判断 → Slack に投げる、の3手だけ。「毎朝必ず動くことに価値があります」）。②相手ボールの放置検出（タスクはただの Markdown チェックボックスで、@waiting だけ自分で決めた記法。@区分 / !優先度 / ~期限 / @waiting:ボールが渡った日 を1つ埋めておくだけで、あとの自動化が全部 grep で書ける）。③入口は3つ（PC のローカル起動／スマホから Pi の常駐セッションをリモート操作／Slack は補助）で、読み書きする先は同じ1つのリポジトリ。
④が設計として重要でした。見つける係と、やる係を分ける。
「両方に外を見せると、同じ用件を別のキーで拾って二重に作業します」。そして「戻せる作業は聞かずに終わらせて、終わってから報告してくる」（返信案、資料のたたき台、調査、コードの修正）。戻せない操作だけ「あとは送るだけ」で止まる。判断だけが手元に残る設計です。
⑤止まった理由まで書いてくる。案件・顧客・製品の記録／日々の作業ログ／何に時間を使ったか／お金の記録を全部同じリポジトリに入れているから、自動生成の週次レビューがこう書ける——「今週の停滞は種類が違う——事業タスク同士の中での回避。講演資料は『スライド案を複数本並行して作り続ける』という形で、決定という負荷の高い行為を先延ばしにしていた」。「エージェントの出力は、モデルの賢さより何を読ませたかで変わる」という実感が添えられました。
壊しながら作った：ルールは事故のあとに1行ずつ
Chapter 4 が実践の知恵の塊でした。CLAUDE.md に固定した「振る舞いの原則」の実物は、結論から先に述べる／率直に評価する／ファイル作成・編集・移動は確認なしで実行し、やってから報告する／日付に言及するときは必ず date コマンドで現在日時を確認する（環境変数やメモリ上の日付は信頼しない）。前3つは人にも言えることで、4つ目だけAIにしか言わない。理由は「LLMは、時計を持っていません」。渡さないまま期限を計算させて全部ズレた、という失敗から生まれた行です。
「ルールは、最初に完璧に書けません。事故が起きた場所に、1行ずつ足していく」。CLAUDE.md は今200行くらいあるが、ほぼ全部の行の裏側に対応する失敗がある、と。
象徴的な事故が「同じタスクが3つに増えた」件です。Google Tasks に「スライドの決定版を固める（今日中）」「スライド決定版を固める」「【最優先】スライドの決定版を固める ~7/17」が並んだ。真因は毎朝 日次ノートにタスクを書き写していたことで、書き写すたびに文言がズレて同期先から別タスクとして再登録されていた。「AIのせいではありません。同じものが2箇所に存在する設計にしてしまったせいです」。対策として CLAUDE.md に追記した「単一ソース原則」——アクティブな未完了 - [ ] の正本は tasks.md に一本化／同じタスクを複数置かない／daily/ には - [ ] を書かない／「繰越し」という操作は無い。「コピーが無ければ、文言はズレようがありません。運用で頑張るのをやめて、設計で消しました」。
そして任せる範囲の決め方が、このセッションの背骨です。
承認の粒度も設計されています。下書きを作る・書き直す・作り直すは何回でも自由で、送信するところだけ承認。「メールに触るたび承認」にすると1通あたり10件の承認が飛んできて中身を見ずに押すようになるから、原則は「承認を求める回数は、1つの判断につき1回まで」。実際の承認はリアクション1個で、①承認チケットを書く（questions/q-*.md）→②Slack にスレッドを立てる→③承認か却下を押す→④ゲートウェイが即座に受信→⑤承認された操作だけ実行。「私がやるのは、絵文字を1個押すことだけです」。しかもチケットはリポジトリ内のファイルなので「いつ何を承認したかが、コードと同じ場所にバージョン管理されています」。
さらに核心の指摘。「ルールに書く＝お願い」と「ツールを渡さない＝保証」は別物。CLAUDE.md に「メール送信は承認を取れ」と書いてあり守られる確率は高いが100%ではない。だから非同期ジョブにはそもそも送信ツールを渡していない。境界は3か所で引く——disallowedTools（不可逆な操作を deny に。allow より先に評価される）／OAuthスコープ（読み取り専用の資格情報しか持たせない）／実行ホスト（書き込み系は特定のスクリプトからしか起動しない）。外部サービスも「書かないでね」と書くのではなく、書けない資格情報で繋ぐ。「プロンプトはガイドライン。ツールの境界が、権限です」。
料金改定とコストの解決
Chapter 5 は生々しいコスト話でした。2026年5月13日に Claude Code の料金プラン改定が告知され、claude -p（ヘッドレス）と Agent SDK をサブスク枠から分離する方針が示された。「影響を受けるのは、無人で回している人間だけでした」——第二の脳はまさにクリティカルヒットで、cron 15ジョブのうち10本が claude -p 起動でした。
まず台帳化。ジョブ名つきで1回動くたびに1行記録した6週間ぶんの実測がこれです。
| ジョブ | 費用 / 回数 |
|---|---|
| morning-brief | $29.78 / 44回 |
| sync-grizz | $23.14 / 20回 |
| slack-request | $22.21 / 42回 |
| weekly-review | $5.87 / 6回 |
| その他5ジョブ | $5.62 / 23回 |
| closeout-draft | $4.98 / 38回 |
上位3ジョブで82%。「回数が多いジョブが高いわけではありません」（closeout-draft は38回で$4.98、sync-grizz は20回で$23.14）。
対策は3つ。①起動するたびにAIを呼ばない（question_poll.sh の実物は、待っているチケットが無ければ exit 0 →新着の返信が無ければ exit 0（判定は AI 不使用の Python）→単純な承認・却下は AI 無しで実行→残りだけ claude を呼ぶ、の3段ゲート。起動は1分おき＝1日1440回だが、claude を呼んだのは6週間で数回）。「AIを呼ばない判定は、AIの外の安いコードで書く」。②前回から何も変わっていなければ動かさない（state ファイルに前回同期時刻を持ち、Gmail の after: と Drive の modifiedTime > で新着0なら起動しない）。③claude -p を使わずに定期実行する（cron でヘッドレス起動していたものを、Pi 上の常駐セッション内の /loop に移した。処理の中身は1行も変えず、どこで動かすかだけ変えた）。
/loop と /schedule（クラウドの Routines）の比較も実務的でした。
| 観点 | /loop |
/schedule（Routines） |
|---|---|---|
| 動く場所 | 自分のマシン | Anthropic のクラウド |
| マシンの起動 | 要る | 不要 |
| セッション | 開いている必要がある | 不要 |
| 最短の間隔 | 1分 | 1時間 |
| 手元のファイルと認証情報 | そのまま使える | 使えない（毎回 clone） |
自分の構成で選べたのは /loop だけだった理由が「Gmail と Drive のトークンは ~/.config/brain/ にあり、家計の生データは .gitignore 済み。どちらも毎回 clone されるクラウドには現れない」。「クラウドに移せなかったのは性能でも料金でもなく、認証とデータが手元にあるからです」。
/loop の弱点（7日で失効し、tmux セッションは生きたまま残るのでエラーも出ず黙って止まる）への対策として、作り直す cron を1本足す（毎日3:10）。工夫は①深夜に置く（目標時刻からいちばん遠い時間）②落とす前にロックを取る（flock で .git.lock を共有）③無ければ起動する。「cron を減らすために移したのではありません。ヘッドレス起動の分を定額枠に残すために、重い同期ジョブだけを移しました。ジョブの実体は /loop、セッションの生存管理は cron。役割を分けただけです」。
なお料金改定については重要な注意が添えられました。2026-06-15の施行当日に一時停止され（「For now, nothing has changed」）、講演当日（7/30）時点でも停止のまま。「したがって今日の数字はサブスク枠での実測であり、円で請求が来ているわけではない」。それでも対策は1つも戻していない理由が「測ったら課金形態と関係なく上位3ジョブで82%を食っていたから」。「課金の形が変わらなくても、何にいくらかかっているかは、知っておいて損はない」。
やってみて分かったこと、そして製品への還流
50日ぶんの答え合わせとして、自動生成された週次レビューの文章が引かれました。「『講演資料提出（〜7/17）』が9日間『今日中にやる』と言われ続けて未解決。会議で2度『共有』しても実行に移っていない。次に同じ指摘を書いても効果はない」「選択肢を増やす作業は『進んでいる感』を出せるが、実際は決定回避」「技術タスクの完遂に逃げて、条件交渉という気が重い意思決定を回避している構造が見える」。しかも指示していないのに、AI自身が出した通知についてもこう書いていたそうです。「同じ警告を4日連続で出し続けて行動が変わらなかった時点で、『今日中に』という抽象的な指摘では機能しないと判断すべきだった。（中略）日々の自動提案が同じ文言を繰り返すだけになっているなら、それは通知の形骸化であり、優先度を上げる／エスカレーション方法を変えるべきサイン」。
そして総括が効いています。「壊れたのは、ぜんぶ AI の外側だった」——仕事が止まった理由を説明できない（→日々の作業ログも同じリポジトリに入れた）／同じタスクが3つに増えた（→正本を1つに決めて繰越しをやめた）／不可逆な操作がルール頼りだった（→送信ツールをそもそも渡さない）／ヘッドレス起動が別料金になる告知（→起動と課金を分けた）。「ぜんぶ、壊れてから足しました。先に4つ決めて作ったわけではありません」。
エピローグでは、この個人リポジトリの設計がそのまま製品（KumaKumaAI の note 機能）へ還流している話が語られました。①刻まずに蒸留してから置く（チャンク＋ベクトルではなく、AIが蒸留して1ノート＝1トピックにし、話が繋がったまままるごと渡す。精度が上がる3点＝断片ではなく全文／単一ソースに統合／出典を辿れる、はすべて個人リポジトリで先にやっていたこと。正直な注意として「トークンは増える」も明示）②探す手順を書いておく（CLAUDE.md の探索順が、製品ではツールの並び LIST_NOTE_FOLDERS → SEARCH_NOTES → READ_NOTE の往復になっている）③可逆性の線引きもそのまま入った（ノート層のメンテジョブが、置き場所のズレ＝自動適用／空フォルダ整理＝承認後／重複ノートの統合＝never auto-merged）。「毎日自分で使っていると、どこが効いて、どこが要らないかが先に分かります」。
セッション5：AI開発におけるガバナンス 🛡️
（新田 祐介氏／LINEヤフー）
メディア・検索ドメインのメディアCTO SBU 開発推進ユニットリード／Principal Architect という立場から、「事業横断の視点」でのガバナンス設計の話でした。
目指す姿：攻めと守りの両立
AI駆動開発の目的は、攻めと守りを両立した上での生産性向上・事業貢献。攻めは開発プロセスの加速（要件定義・設計・実装・テストをAIに任せられる状態）で、ここで「生産性向上が目的であるためAIの導入が目的ではない」と注意が置かれます。守りが本日のポイントで、品質保証とガバナンスの実現（AI成果物の品質と信頼性の担保／コストに見合った成果が出せていること）。事業貢献（提供価値・利益の最大化）のため、1人あたり生産性の向上を大目的として動いている、という整理です。
AI Ready にしてから、利用を拡大する
プロセスの全体像が2段階で示されました。
AI Ready 側の「既存プロセスの最適化」の中身が示唆的でした。過剰・重複している業務の見直し（AI化した時にAIを使いすぎないように、削減出来る業務は削減する）と、明文化・言語化の徹底（Single Source of Truth のために、口頭で伝わっていた属人的な仕様を排除）。AI を入れる前に、無駄な業務ごと自動化してしまわないための工程です。
利用拡大側は3ステップ。①既存プロセスへのAI導入（個人単位・プロセスは変えずに導入、セルフレビュー等への活用）②プロセス再構築（AI前提のプロセス設計、人は指示と判断に専念）③AI中心への移行（AIが自律的に設計から開発・テストまで行う最終ステップ）。
コスト面と品質面の課題、そして優先順位
課題の整理と「どちらを先にやるか」の判断が、このセッションの実務的な価値でした。
コスト面は3つ。①不適切なAI利用によるコスト増加（高単価モデル利用、アンチパターンなプロンプトによるトークン増）②誤ったAIエージェント利用によるコスト増加（意図しない自律動作＝Agent Loop の無限ループ化）③費用対効果の計測。①②は「上限設定など事後のガードレールが必要」、③は「事前のKPI設計、リリース後のモニタリングが必要」。結論は「定量的に判断出来る事後のガードレールから導入が必要」。
品質面も3つ。①AIが作業中に個人情報・機密情報を外部に送信するリスク（作業ディレクトリに機密が含まれていた／外部送信前に人のチェックがなかった）②AIの成果物に脆弱性が組み込まれるリスク（参照している外部リソースがサプライチェーン攻撃対象だった／脆弱なコードが生成される）③品質が低いことによる技術的負債の蓄積。①②は「事前に検知しなければならない項目」、③は「インシデント観点では事後でも可（許容項目）」。結論は「インシデントは起こしてはならないので、最優先で事前の対策が必要」。
つまり、コストは事後ガードレールから、品質は事前検知から。同じ「対策」でも軸によって着手順が逆になるという整理で、ここは持ち帰り価値が高いところです。
課題のまとめは3点——AIへの過剰投資・過剰利用を制御するコストコントロール／AI成果物に脆弱性が入らないための事前対策／機密情報・個人情報漏えいなどへの事前対策。
具体策：ガードレールと生産性ツリー
コスト面の対策のうち、トークン利用のガードレールは3ステップで運用されています。①利用量の計測・管理（社内共通の仕組みで可視化）②上限超過時の利用制限（全体でのハードリミットと個人単位でのソフトリミットの2種類）③超過管理・上限見直し。継続課題として「個々人のユースケースを考慮した上限設定が出来ていない」点が正直に挙げられていました。
生産性の計測は、提供価値をルートとしたツリーで行われます。
ツリーの各項目の数値を評価して施策の確からしさを検証し、評価は複合的に実施する。単一指標で判断しない姿勢です。
品質面は「当たり前にやれてきたことをAI領域にも適用」というスタンスで、①AI利用のガイドライン策定（機密情報・個人情報が存在するフォルダでの作業は行わない／AI成果物が人の許可なく外部にアクセスしないようにする／各種リソースに対する更新作業〈削除も含む〉は人の確認を必須とする）②AI利用のガードレール導入（共通のセキュリティ設定を行う社内ガードレールの提供）③品質指標のモニタリング（インシデント数、ユニットテスト網羅率などの品質ゲート継続運用）。
対策後の継続課題も率直でした。職種ごとの利用特性に応じたコストコントロール（月次は超過しないが日次で超過することがあり、定量面だけで管理出来なくなってきている）／AI利用における費用対効果の確認方法／機械的で継続性のある品質ガードレールの構築。まとめは、AI駆動開発は事業貢献が大目的（AI導入を目的化しない）／生産性を複数指標で継続的に計測・評価する／AI開発に適した品質対策を講じる、の3点でした。
セッション6：大規模製造業でのAI駆動開発との向き合い方 🏭
（前川 博志氏／ダイキン工業）
1日目の締めは、テクノロジー・イノベーションセンター主任技師の前川氏。冒頭に問いを立てる構成でした。「製造業でAI駆動開発って、大変でしょ？」→「はい、大変です。製造業ならではの、考えるべきことが多くあります。でも、**"大変なだけではない"**とも思います」。この問いに最後のスライドで答える、と予告してのスタートです。
立ちはだかる4つの現実
ダイキンは売上の9割超が空調事業で、ハードウェアの品質で信頼を築いてきた会社。しかしソフトウェア領域が拡大し（機器の組込み制御／IoTプラットフォーム・クラウド／業務システム・データ活用／ソリューション事業）、ハード単体では差別化しにくい時代に入って「ソフトが競争力の中心に」なってきた。そこでAI駆動開発への期待が生まれる——のですが、その前に4つの現実が立ちはだかります。
| 現実 | 内容 |
|---|---|
| 規模と分業 | 多数のシステム群、パートナーとの分業が前提の開発構造 → 要求・設計・実装・運用の間で知識が分断されやすい |
| ハードウェア品質の文化 | 「不具合を出さない」ための重厚なプロセスと審査 → スピードよりも品質担保を優先するガバナンスが根付いている |
| ドメイン知識の壁 | 空調・冷媒・組込み制御の固有知識は世の中のLLMにはない |
| 秘密情報・セキュリティ | 製品・顧客情報を扱う以上「とりあえずクラウドAI」とはいかない |
結論は「一般的な『AI駆動開発』プラクティスをそのまま輸入しても、大規模な変革に繋がらない」。知識が循環しない構造も具体的で、企画・要求（ダイキン）→設計・実装・試験（パートナーと協働）→受け入れ（ダイキン）→運用・保守の各段階で、WHYが製造工程に伝わりきらない／設計判断・知見が集約困難／認識違いで受け入れが往復／改善よりも安定を指向、が起きている。
それでもAI駆動開発に賭ける理由が語られます。AIは「補完ツール」から「設計・実装・検証の一部を自律的に担う存在」へ進化した。任せるしかなかった作業をAIと内製できれば、知識が社内に蓄積される構造に変えられる。「LLMは良くも悪くも入力から出力を予測するモデルのため、入力（文脈・知識）の整備が必須要件になる」。狙いは工数削減にとどまらず、開発力と組織学習力の再構築。そして最後に一言、「そして単純に——開発者として、いまが一番面白い」。
現場で見えたこと：D-Arc の世代交代
ボトムアップの実践として、AIコードレビューシステム「D-Arc」の話が出ました。変数・観点ごとに網羅的にレビューするシステムで、機械的に変数を抽出し「何に着目するか」をプロンプトで与える構成です。面白いのはその2年間の変化です。
「『D-Arc が AI を使う』から、『AI が D-Arc を使う』へ」。この転換から得た教訓が3つ挙げられました。①前提は数ヶ月単位で崩れる（「必要な情報をプロンプトに詰めてAPIを呼ぶ」前提がエージェントの登場で崩れた。作り込んだ仕組みほど時代が変わったときに重荷になる）②現場導入の最大の壁は技術ではなく「動作イメージの共有」（ロジックを何度も説明するより、最小限のものを作って出力を見せるのが最速）③網羅性を追求すると「重くて高い」システムになる（スケールとコストは後付けではなく最初から設計に織り込む）。「こういったことは、現場で実践しないと実感できない ⇒ まだ教科書がない領域での経験は、実際には計り知れない」。
個人の動き方についても、Gene Kim & Steve Yegge の FAAFO（Fast / Ambitious / Autonomous / Fun / Optionality）を引きながら語られました。「相談を受けたら、完成品を持って行って議論する」働き方へ。設計相談で仕様一式をもらったらミーティングまでに動くものを作る。バイナリしか残っていない自社のレガシー資産も、AIとリバースエンジニアリングして改善提案。3営業日以内に"動くもの"で返す——「相手は最初ビビる。そして、組織が動き出す」。こうした動き方には FDE（Forward Deployed Engineer）という名前がつき始めていて、「エンタープライズにも切り込み隊長は必要」「せっかくの魔法なんだから——まず自分が、マジメにAIに"狂って"みせる」。
熱量を広げる仕掛けが社内コミュニティ「D2 Lounge」（Daikin Developers' Lounge）で、参加者約400名・週次アクティブ約200名の「生きた」コミュニティ。一番の盛り上がりは「AIコーディング」チャンネルで、Claude Code ハンズオン（3日間の集中研修を内製化中）や AI-DLC ハンズオンも実施・計画中。「ボトムアップの熱量が、トップダウンの施策を受け止める土壌になる」。ただし——「個人とコミュニティの頑張りだけでは、この先に限界がある」。
組織としての向き合い方：ハーネスと三点セット
ここが3章の本題です。「個人の"魔法"は、組織ではそのまま"事故"になり得る」。規模が大きいほど早く顕在化する課題として、生成AI成果物の品質を保証するスキル不足／活用ノウハウが個人経験に依存し定着しない／部門ごとに方針・ツール・品質判断がバラバラで重複開発／AI技術の進化が速すぎて個人の努力では追従しきれない、が挙がりました。
制御のないAIエージェントに潜む危険は4つ。①根拠のない出力（ハルシネーション・未検証の成果物が「完成」として届く）②秘密・脆弱性の混入（秘密情報のハードコード／脆弱な実装／汚染されたOSSの取り込み）③環境の破壊（本番環境への誤操作・誤デプロイ・情報漏えい）④ブラックボックス化（判断・操作の証跡が残らず、後から説明できない）。「コーディングエージェント単体では『安心して任せられる』状態には決してならない」。
その答えが「ハーネス」です。
定義が明快でした。「ハーネス ＝ 人間が定めた原則・判断基準を、開発プロセスとして実行可能にする仕組み」。現在構築中の具体例として、サンドボックス（AIの作業場を隔離し環境破壊を封じる。情報の持ち出しは資格情報の隔離とegress制御で別途防ぐ）／ガードレール（危険操作・秘密情報漏えい・プロンプトインジェクションを多層の制御で抑え込む）／品質ゲート（型・静的解析・テストなど決定論的な検査を土台に、別AIのレビューを補助として重ねる）／ドキュメント自動整備（ADR や説明資料をAIが起草し人が承認して記録に残す）／コスト可視化（誰が・何に・いくら使ったかを記録し、ダッシュボードと上限制御で青天井を防ぐ）が並びました。
そして「ハーネス（道具）だけに、頼らない」として三点セットが提示されます。①決まりごと＝ガイドライン（NIST AI RMF などを参照し自社文脈で整理。ツールの手順書ではなく判断の拠り所）②仕掛け・仕組み＝ハーネス（ルールは決めるだけにせず守れる形で配る。ガイドライン・検査手順は Agent Skills として配布）③横のつながり＝コミュニティ / CoE（D2 Lounge で実践知を交換し、上級者の実践知をハーネス・ガイドラインへ還流）。
しびれたのがこの続きです。「この三点セットの組織展開——実は、私たちには"一度目"の経験がある」。AWS を社内に広げたときの構造がまったく同じだった、と。①AWS設計指針（暗黙的・散逸的だった知識を自分たちで書いてまとめ、社内セキュリティルールと整合させた）②チェックの自動化（ルールをIT部門と合意しチェックリスト化、AWS Config で自動検知する仕組みを内製、セキュリティプロセスを大幅にシフトレフト）③コミュニティ ACDC（失っても許せる範囲の"小さな一歩"で立ち上げ、200名超に成長して現在の D2 Lounge へ統合）。「押しつけの基盤にせず、ボトムアップで広げて全社の標準に——同じことを、AIでやる」。
進め方の軸として、サラスバシーの「エフェクチュエーション」5原則（手中の鳥／許容可能な損失／レモネード／クレイジーキルト／パイロット）も紹介されました。未来を予測して逆算するのではなく、手持ちの資源から始めて目的を創造していくアプローチです。
変わるもの／変わらないもの
4章がこのセッションの結論部でした。まず「"○○エンジニアリング"の乱立」を整理——Spec駆動開発（何を作るかを仕様として固める）／コンテキストエンジニアリング（AIに渡す文脈を設計する）／ループエンジニアリング（検証可能なゴールを与え自律ループを設計する）／ハーネスエンジニアリング（エージェントの実行基盤と統制を設計する）／グラフエンジニアリング（複数エージェントの組織・知識を配線する）。そして「共通する前提：検証可能なゴール（何をもって良しとするか）× 安全機構（何をしてはいけないか）」。
| 変わるもの「どう早く作るか」 | 変わらないもの「どう品質を定義するか」 |
|---|---|
| エージェントも手法も数ヶ月で進化し陳腐化する／「○○エンジニアリング」の語彙も回転し続ける | 受け入れ基準（何をもって完成とするか）／品質ゲート（工程の中で品質を作り込む）／検証手法・証跡・トレーサビリティ |
| → 作り込みすぎず、乗り換え前提で「軽く」持つ（手法は「輸入」ではなく「実験」） | → ここへの投資は、腐らない |
「ハードウェア品質の文化——品質を工程で作り込み、基準と証跡で保証する型。それこそが、AI時代の『変わらない側』を支える、製造業最大の資産」。AIのちからは「どう作るか」、人と組織の仕事は「何をもって良しとするか」を定義し続けること。
その「品質の定義を実装する」実例が具体的でした。「センサー値が欠落・異常のとき、装置は必ず安全状態に遷移する」という品質要求を、4つの手法で機械判定可能にします。
| 手法 | やること |
|---|---|
| BDD | 要求を実例シナリオとして記述し、そのまま実行可能なテストに（Given センサー値が<異常> / When 制御を1周期実行する / Then Safe = true）→ 代表シナリオが成立する |
| Property Based Testing | 「どんな異常値でも安全状態」という性質を定義し、自動生成した大量のケースで検証 → 多様な異常入力でも性質が崩れない |
| Mutation Testing | 安全判定のコードに意図的に欠陥を注入し、テストが見逃さないか（検出力）を測る（if Fault(v) を if !Fault(v) に変異）→ 欠陥を入れるとテストが失敗する |
| 形式手法（Alloy など） | 状態遷移をモデル化し、有限スコープ内を網羅探索して「安全に遷移しない反例」を探す → モデル上に安全違反の反例がない |
「機械判定できる受入基準と検証器を品質ゲートに組み込む」。ここまで具体的に「良しの定義」を実装で語ったセッションは、この日ほかにありませんでした。
スケールさせるための現実問題も3点。コスト（従量課金は「青天井」で組織として最も怖い。モデル単価は下がり続けてもエージェントの利用量がそれを上回り請求は伸びる。可視化・上限制御・成果あたりコストの計測を最初から。ローカルLLMの選択肢も持つ）／自律度（成熟度の一本道ではなく「リスク」で決める。影響範囲・可逆性に応じて HITL / HOTL を使い分け、高リスク操作は恒久的に事前承認でよい。エンジニアの役割は「書く」から「束ねて監督する」へ）／変化（ハーネスは「作品」ではなく「変化に追従する仕組み」。特定のAI・サービスに依存しない設計、短い検証サイクルで方針を更新し続ける）。
そして冒頭の問いへの回答です。「製造業でAI駆動開発って、大変でしょ？」→「はい、大変です。でも、私たちを縛ってきた"壁"——検証を求め続ける品質文化は、AI駆動開発の時代、我々の最大の"武器"になる」。そして最後のスライド、「問いを変えませんか。『大変でしょ？』から、『いちばん面白い場所でしょ？』へ」。1日目の締めにふさわしい終わり方でした。
1日目を通して見えた共通テーマ 🧵
ベンダー・コンサル・金融・個人開発者・Webサービス・製造業。立場がまったく違う6セッションが、独立に同じ場所へ着地していました。3つにまとめます。
テーマ1：「安心して任せる」はハーネスで作る。 Cognition は基盤モデルの進歩ではなく「ハーネスエンジニアリングで実現した特化型エージェント群の協調」でPRマージ率を倍にしたと語り、藤田氏は「プロンプトはガイドライン。ツールの境界が、権限です」と言い切り、LINEヤフーはガードレールと品質ゲートを社内共通機能として配り、ダイキンは「コーディングエージェント単体では『安心して任せられる』状態には決してならない」と断じてハーネスの4段構成を示しました。ルールに書くこと（お願い）とツールを渡さないこと（保証）は違う、という認識が独立に4者から出てきたのが、この日いちばんの発見でした。
テーマ2：任せる範囲は「可逆性 × 検証可能性」で決める。 Cognition の A/B/C 3軸（検証可能性・量反復性・失敗コスト）、藤田氏の「AIの賢さではなく操作の可逆性で決める」、LINEヤフーの「各種リソースに対する更新作業（削除も含む）は人の確認を必須とする」、ダイキンの「成熟度の一本道ではなくリスクで決める。影響範囲・可逆性に応じて HITL / HOTL」。表現は違えど、線を引く座標軸が同じです。しかも Cognition が「A・B・C はタスクの固定属性ではなく、渡し方と環境整備で動かせるレバー」と付け加え、藤田氏が「スコープを提案までに切れば可逆になる」を実装していたように、軸は動かせるという点まで一致していました。
テーマ3：「良しの定義」と「人を育てる」は人間の仕事。 ダイキンが「AIのちからは『どう作るか』、人と組織の仕事は『何をもって良しとするか』を定義し続けること」と述べ、それを BDD・Property Based Testing・Mutation Testing・形式手法で実装まで見せた。Cognition は「曖昧な要求を検証可能なスペックに翻訳し、エージェント艦隊を設計・監督する判断力」へ価値が移ると言い、ULS は経験学習モデルが回らなくなる危険を研究3本で示してジュニア育成を訴え、みずほ証券は PoC で「領域でもシステムでもなく『人』を選抜する」と言いました。受入基準を書くのも、それを書ける人を育てるのも、AIには委譲できないというのが、この日の結論だったと思います。
共起ネットワーク：1日目の語彙はどう繋がっていたか 🕸️
セッションの内容を振り返るついでに、聴講メモそのものを分析対象にしてみました。メモの箇条書き1行を「文書」とみなして（対象381行）、どの語とどの語が同じ行に一緒に登場するかを集計した、共起ネットワークです。円の大きさが出現頻度、線の太さが共起の強さ（Jaccard係数）、色が媒介中心性——つまり「その語がどれだけ他の語同士を繋ぐハブになっているか」を表しています。
出現頻度の上位はこうなりました。
| 順位 | 語 | 出現 |
|---|---|---|
| 1 | 設計 | 39行 |
| 2 | コスト | 38行 |
| 3 | レビュー | 30行 |
| 4 | プロセス | 29行 |
| 5 | ナレッジ | 26行 |
| 6 | 品質 | 26行 |
| 7 | エージェント | 25行 |
| 8 | テスト | 24行 |
| 9 | リポジトリ | 24行 |
| 10 | 組織 | 23行 |
「AI」や「エージェント」よりも「設計」「コスト」が上に来たのが、この日の性格をよく表していると思います。技術そのものより、それをどう設計し、いくらかかるかを語る一日だったということです。
共起の強い組み合わせ（同じ行に一緒に出てきやすいペア）も見てみます。
| 組み合わせ | 共起 | Jaccard係数 |
|---|---|---|
| 実装 – 設計 | 9回 | 0.200 |
| 判断 – 設計 | 9回 | 0.173 |
| プロセス – 仕組み | 6回 | 0.158 |
| エージェント – クラウド | 5回 | 0.143 |
| 検証 – 設計 | 7回 | 0.140 |
| コスト – 可視化 | 6回 | 0.133 |
| エージェント – ナレッジ | 6回 | 0.133 |
| テスト – プロセス | 6回 | 0.128 |
「実装 – 設計」が最上位なのは当然としても、次に「判断 – 設計」が来るのが面白いところです。この日くり返された「AIは作業を肩代わりするが判断は肩代わりしない」「判断・意思決定へ価値が移る」という話が、語の共起としても現れています。「コスト – 可視化」も同様で、コストの話をするときは必ず「測る」がセットで語られていました（LINEヤフーの計測・上限制御、藤田氏の台帳化、ダイキンのコスト可視化）。
媒介中心性（ハブ度）の上位も示唆的でした。
| 順位 | 語 | 媒介中心性 |
|---|---|---|
| 1 | ナレッジ | 0.249 |
| 2 | 設計 | 0.222 |
| 3 | 顧客 | 0.174 |
| 4 | プロセス | 0.148 |
| 5 | エージェント | 0.126 |
図の中で赤く大きく描かれている「ナレッジ」と「設計」が、話題の異なるセッション同士を繋ぐ結び目になっていました。ナレッジは、Cognition の「組織的なノウハウ」、ULS の「知識が中心」「モブ的にナレッジを蓄積」、みずほ証券の「Snowflake のナレッジコンテキスト」、ダイキンの「知識が循環しない構造」、藤田氏の「恒久ナレッジ」と、6セッション中5つで別の文脈から語られた語です。3位に「顧客」が入っているのも、AI駆動開発の話をしているようで実は顧客価値の話をしていた、というこの日の性格を映しています。
面白いのは、この集計が最初の3テーマ（ハーネス／可逆性×検証可能性／良しの定義と育成）と綺麗には一致しない点です。「ハーネス」という語自体の出現は多くありません。言葉としては別々に語られていたのに、指している構造が同じだった——だからこそ、まとめの3テーマは語の頻度ではなく、話の骨格を読み取って初めて見えるものだった、とも言えます。共起ネットワークは全体の地形を示してくれますが、山の名前を付けるのは読み手の仕事だ、という当たり前のことを再確認しました。
💡 この図は、筆者個人の聴講メモを対象に、行を文書単位として語の共起を集計したものです。抽出語と表記ゆれの統合（例:「知識・ノウハウ」→ ナレッジ）は筆者が定義しており、定義を変えれば別の図になります。講演の内容そのものの統計ではない点にご注意ください。
私自身の持ち帰りを一つ挙げるなら、藤田氏の「壊れたのは、ぜんぶ AI の外側だった」です。同じタスクが3つに増えたのも、期限計算がズレたのも、モデルの賢さの問題ではなく設計の問題でした。ダイキンの「変わらない側への投資は腐らない」と合わせて読むと、いま自分が手を入れるべきなのは、プロンプトよりも先に「正本を1つに決める」「受入基準を機械判定できる形にする」「不可逆な操作にツールを渡さない」あたりだと分かります。まずは自分のリポジトリで、同じ情報が2箇所にある場所を探すところから始めてみます。
参考
- AI駆動開発カンファレンス 2026夏
- セッション1: Opening Keynote「コーディングの終わりと、ソフトウェア開発の始まり〜Cognitionが考えるソフトウェア開発の未来〜」正井 拓己氏 / シバタ アキラ氏（Cognition AI Japan）
- セッション2: Lunch Session「人月モデルの崩壊とこれからの人材育成」漆原 茂氏（ULSコンサルティング）
- セッション3: Special Speaker「みずほ証券スタイルのAI駆動開発 ― これまでの取り組みと今後のビジョン」杉谷 剛氏（みずほ証券）
- セッション4: 「『寝てても仕事が進む』Claude Codeで組む第二の脳」藤田 智也氏（Grizzlarity）
- セッション5: 「AI開発におけるガバナンス」新田 祐介氏（LINEヤフー）
- セッション6: 「大規模製造業でのAI駆動開発との向き合い方」前川 博志氏（ダイキン工業）
- 講演内で引用された文献: コルブ『最強の経験学習』／CHI'25 "The Impact of Generative AI on Critical Thinking"／PNAS "Generative AI without guardrails can harm learning"／ACM Opinion "Redefining the Software Engineering Profession for AI"／NIST AI RMF／S. サラスバシー「エフェクチュエーション」／Gene Kim & Steve Yegge "FAAFO"