こんにちは。ファインディ株式会社でプリンシパルエンジニアをしている戸田です。 2026年8月5日(水)に、Findy AI Meetup in Fukuoka #7を福岡で開催しました。当日参加くださったみなさま、ありがとうございました！ findy-inc.connpass.com 今回のテーマは「AI開発の"今まで"と"これから"を語り尽くそう」です。 皆さまの熱いご支援のお陰で、Findy AI Meetup in Fukuokaは今回で1周年を迎えました。節目となる今回は、AI開発のこれまでを振り返りつつ、これからを見据える内容の登壇が揃いました。 この記事では、ファインディメンバーによる2つの登壇を振り返ります。 Findy AI Meetup in Fukuokaについて え？フロントエンドエンジニアのワイがインフラも！？ 「開発は一人です」から始まった新規サービス 武器は社内に揃っていた 2つの誤算 変わったこと、変わらなかったこと VibeCodingからAgenticWorkflowへ 速くなったのは開発工程ではなくコード生成 レベル1「速く作る」— VibeCodingと現場の課題 レベル2「正しく作る」— 協働から委任へ ターミナルへの回帰 — 開発環境そのものが変わった 順番を間違えない — 基本が先、AI活用は後 まとめ Findy AI Meetup in Fukuokaについて Findy AI Meetupは、ファインディのエンジニアが主催する技術系オフラインイベントです。 生成AIやAIエージェントの活用を通じた開発生産性の向上をテーマに、社内での実践事例の紹介やエンジニア同士の交流を目的としています。 福岡での開催は今回で7回目、そして1周年となりました。この1年でAI開発の景色は大きく変わりましたが、回を重ねるごとに参加者同士の交流も深まり、福岡のエンジニアコミュニティとして根付いてきたことを実感しています。 え？フロントエンドエンジニアのワイがインフラも！？ まずは、フロントエンドテックリードの新福による登壇です。フロントエンドエンジニアが生成AIとともに専門外の領域へ越境した実体験をお話ししました。 speakerdeck.com 「開発は一人です」から始まった新規サービス きっかけは、新しいサービスの立ち上げでした。ファインディでは生成AI時代のプロダクトが次々に生まれており、立ち上げ期のプロダクトは少数精鋭・スピード重視で職種の枠に囚われないフルサイクル志向となることが多いです。 そんな中で、新規サービス開発を任されることになりました。ただし、人員の確保が難しいため開発は一人です。これまでなら、良いアイデアがあっても専任のメンバーが足りなければ諦めるしかありませんでした。 しかし、生成AI時代ならそれも可能かもしれません。そう考えて、フロントエンドはもちろん、バックエンド、そして完全に初見のインフラ（AWS/Terraform）まで、全部を一人で担当することにしました。 領域 内容 フロントエンド 本来の専門領域 バックエンド Honoを採用、テーブル設計などは専門メンバーによるレビュー インフラ（AWS/Terraform） IAM、VPC、ECS、RDSなど、SREチームによるレビュー 武器は社内に揃っていた 挑戦を支えたのは、弊社SREチームが整備していた社内資産でした。Terraformやバックエンド側APIのスターターキット、社内標準の構成を再利用可能な形にまとめたAWS汎用モジュール、そして環境構築を手助けするエージェントスキルです。 これらの社内資産を活用し、社内の作法に沿ったやり方でAIが書き、人間がレビューして判断するという流れで開発を進めました。 結果、アプリケーション（フロントエンド+バックエンド）に約1ヶ月、完全に専門外のインフラに約1ヶ月、合計約2ヶ月で一人で作り上げることができました。 2つの誤算 一方で、やってみて見えてきた誤算もありました。 1つ目の誤算は「時間」です。 当初は生成AIによる開発期間の短縮を見込んでいましたが、実際は専門メンバーやSREチームによるレビュー待ち、そして試行錯誤のたびに発生するTerraformの反映待ちが作業時間の相当部分を占めました。フィードバックを待つ必要があるものはAIでの高速化が難しく、AIが圧縮したのはあくまで「人間が考える時間」だったのです。 2つ目の誤算は「理解」です。 自分で書いていたときは、仕組みや依存関係を把握しなければそもそも書けないため、両者は常にセットで、疑う機会すらありませんでした。ところが生成AIに書かせると、内容を把握せずとも書けてしまいます。そのまま進めると、なぜ動くか、あるいは動かないかがわからず、インフラでこれは致命的となり得ます。だからこそ、浮いたはずの時間の一部を使って、生成AIの出力を読んで理解する時間を確保する必要がありました。まさに「思考は外注できるが、理解は外注できない」を実感した経験となりました。 変わったこと、変わらなかったこと 生成AI時代では、着手するまでの意思決定コストが下がりました。これまで人員確保がネックになっていた部分も、生成AIが実装や意思決定のコストを下げたことで、諦めなくても良くなったのです。 逆に変わらなかったのは、最終的な責任を持つのは人間だということです。生成AIの出力を判断するためには、結局のところ実装者自身が仕組みを理解し、専門知識を身につけなくてはいけません。 生成AIの発展により、越境しやすい環境になりましたが、専門知識の価値は変わりません。「理解は外注できない」という事実をしっかりと頭に留め、基礎を大事にするというのがこの挑戦から得られたものでした。 VibeCodingからAgenticWorkflowへ 続いて戸田からは、ファインディがこの1年で歩んできたAI活用の変遷を「VibeCodingからAgenticWorkflowへ」と題してお話ししました。 speakerdeck.com 速くなったのは開発工程ではなくコード生成 出発点は、AIを導入して見えてきた現実です。AIが高速化したのは「コードを書く」工程だけで、レビューや検証といった「正しいか」の確認に時間がかかり、開発フロー全体のスループットは横ばいのままでした。これは体感ではなく、可視化した数値が示した事実です。 速くコードを書けても、理解せずに生成されたコードは質が落ち、レビューでの指摘が増え、結局速さの恩恵が消えてしまう。この連鎖を断ち切るために、ファインディでは「正しい作り方と手順」をハーネス化する開発フロー改革に取り組み、AI活用レベルを3段階に分けて段階的に進めてきました。 レベル テーマ 内容 レベル1 速く作る コード生成の自動化 レベル2 正しく作る モノ作り全体の再設計 レベル3 必要なものを作る 他領域への越境 先ほどの新福の登壇は、まさにこのレベル3「他領域への越境」を体現した実例です。ここからは、そこへ至るまでのレベル1とレベル2の道のりを紹介します。 レベル1「速く作る」— VibeCodingと現場の課題 レベル1は、VibeCodingでコードを生成し、Pull requestを作成してレビュー依頼を投げるところまでをAIで自動化するフェーズです。 ただしこのフェーズでは、現場で次のような課題が起きていました。活用レベルの個人差が大きい、AI出力の合否判断ができないまま理解せずにレビュー依頼を出してしまう、Pull requestの質が低下してリードクラスのレビュー負担が増える、そしてAI主導になり人間側の理解が追いつかない「AIに使われている」状態です。 この課題に対して、まずAIが参照するドキュメントやルールを整えるガードレール整備を行いました。READMEやプロジェクトドキュメントで前提や運用ルールを記述し、AGENT.mdやrulesでコード規約・命名規則・テスト方針をAIに参照させ、よくある作業はカスタムコマンドとして規格化する。ガードレールがあって初めて、AIは「使い物になるコード」を出してくれます。 レベル2「正しく作る」— 協働から委任へ レベル2では、正しい方法と手順を用意して、AgenticWorkflowに委任します。 このフェーズの課題は、要件を実現する手順がAIフレンドリーではないことでした。タスクの粒度や手順を誰も決めておらず、生成AIへ何を渡せば精度よく動くかが属人化している。つまり、明確で簡潔なステップ構造、AIに渡す「設計図」が必要だったのです。 そこで、AIが処理しやすい単位へのタスク分解、構造化された設計図を親子Issueで表現するIssue作成、そしてAIと人間でレビュー領域を分割するコードレビューの再定義に取り組みました。人間はレビューで「作り方と実現方法が合っているか」を検証し、設計図にフィードバックする。タスク分解の品質が、そのままアウトプットの品質を決めます。 このレベル1からレベル2への移行は、AIとの関係性の変化でもあります。登壇では「協働」して書くVibeCodingと、「委任」して任せるAgenticWorkflowの違いを次のように整理しました。 観点 AIとの協働（レベル1 VibeCoding） AIへの委任（レベル2 AgenticWorkflow） 関係性 隣で並走するパートナー タスクを任せる実行者 人間の役割 ハンドルを握る運転手 行き先を決める指揮者 AIの役割 助手席のナビゲーター 自走する実行エージェント 任せる粒度 1行〜1関数 タスク/PR/フロー全体 AgenticWorkflowとは、人間がゴールと制約を与え、AIエージェントが計画・実行・自己検証までを自律的に進める開発スタイルです。ゴール指向、計画と分解、ツール使用、自己検証ループという4つの自律性を備えており、人間の仕事は成果物に対するレビューへと移っていきます。 ターミナルへの回帰 — 開発環境そのものが変わった AI委任の並列性は、開発環境そのものも変えました。2026年からファインディではメインツールがIDEからターミナルへ移行しています。 1ウインドウで1タスクずつ進めるスタイルから、複数ウインドウ・ペインで同時にAIへ委任するスタイルへ。IDEの役割は「すべての開発作業を行う場所」から「広域に渡るコードリーディングで理解を深めるとき」に使うものへと変化しました。AIに並列で任せる前提に合わせて、開発環境が「並列委任しやすいもの」へ変わってきているのです。 順番を間違えない — 基本が先、AI活用は後 最後に強調したのは、順番を間違えないことです。土台が弱いと、ガードレールもAIも成果を出せません。 統一規約・型定義・テストコードといったコード品質をまず充実させ、Pull requestの粒度やレビュー文化といった開発文化を育てる。その上でガードレール・ハーネスを整備し、最後にAI SkillやPluginを横展開して組織全体でAI活用を加速させる。基本が固まってからAI活用を載せる、この順番が重要です。 AI時代の本丸は「速く作る」ではなく、「正しく作る」「必要なものを作る」への段階的な越境です。人間の役割はコードの読み書きから、何をどう作るかの判断へと上流に移っていきます。それでも、やるべきことはAI以前から変わりません。基本の徹底こそがAI活用の大前提なのです。 まとめ 今回のテーマは「AI × これまでと、これから」でした。 2つの登壇に共通していたのは、AIによって変わったことと変わらないことの整理です。変わったのは、AIに任せられる範囲です。職種の壁を越えることが現実的な選択肢になり、協働から委任へと関係性も進化しました。変わらないのは、理解と責任が人間に残ることです。AIにどれだけ委任しても、出力を判断する専門知識と基本の土台がなければ、AIは成果を出せません。 この1年でVibeCodingという言葉が当たり前になり、いまはAgenticWorkflowへの移行が始まっています。これからも変化は続きますが、基本を固め、理解を手放さず、段階的に任せる範囲を広げていく。この姿勢は変わらないと考えています。 なお、登壇でも紹介したファインディの開発知見は、ドキュメントサイト「Findy Library」で公開しています。開発の基本からVibeCodingやAgenticWorkflowの実践まで、今回の登壇のベースになっている知見をまとめていますので、ぜひ活用してみてください。 lib.findy.co.jp そして早くも次回開催が決定しました！2026年11月12日(木)に開催予定です。次回は「AI × 並列開発 AIに委任して変わりゆく開発手法」と題しまして、AIへの委任で変わっていく開発手法について語り合う会にしたいと思っています。今回の登壇でも触れた「並列委任」をさらに深掘りするテーマです。ぜひご参加ください。 findy-inc.connpass.com ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 生成AIが開発現場に入り込んでから1年あまり。Claude CodeやGitHub Copilotなどのエージェント型ツールも一般的になってきました。 その一方で、「AIを導入したのに、思ったほど速くなっていない」「むしろレビューが大変になった」という声を、社内外でよく聞くようになりました。 そんな中で先日、弊社主催の「AI Engineering Summit Tokyo 2026」にて 「速く作る」から「正しく作る」へ ─ 生成AI時代の開発フロー改革のロードマップと実行 ─ と題して登壇してきました。 ファインディ社内で1年強かけて見えてきた「AI導入の落とし穴」と、そこから組み立てた3段階のロードマップを共有する内容です。 ai-engineering-summit-tokyo.findy-tools.io この記事では登壇内容を振り返りつつ、AI導入の効果が伸び悩んでいる組織に向けて、ファインディがどのような順番で開発フローを作り変えてきたかを紹介します。 それでは見ていきましょう！ AIを入れたのに、アウトプットは伸びていなかった 「速く作る」だけでは限界がある AI活用レベル レベル 1：AIエージェントでコード生成 レベル 2：AIエージェントでモノを作る レベル 3：AIで価値を生み出す まとめ AIを入れたのに、アウトプットは伸びていなかった ファインディも同様に生成AIの本格活用を進め、Claude CodeやCodexなどのAIエージェントが日常的な開発フローに入り込んできました。社内の体感としては「1人あたりのPR作成数も増えていそうだし、開発のリードタイムも短くなっているはず」というものでした。 しかし、Findy Team+で1年分の数値を計測してみると、想像とは違う景色が見えてきました。 まずポジティブな変化として、PR作成総数は前年比で伸びていました。ただ、その内訳を見ると、稼働メンバー数が約1.5倍に増えていたことが大きく、1人あたりのPR作成数はほぼ横ばいだったのです。 さらに、レビュー開始からApproveまでの時間は前年比でおよそ20分延び、PR1本あたりの平均コメント数・レビュー数も約30%増えていました。AIによるコード生成が増えた一方で、レビュー側の負荷が確実に積み上がっていたわけです。 シニア層と若手層で傾向を分けて見ると、もう一段深い構造が見えてきました。AIの出力を読んで検証できるシニアメンバーはアウトプットが上がる一方、経験年数が浅いほどAI出力の合否判断に苦戦する傾向があり、結果としてレビュー側に判断の負荷が集中していました。 組織全体として、 AIに使われている 状態に近かったとも言えます。「体感と事実がズレているかもしれない」と疑い、各種数値を可視化していたからこそ、実は「1人あたりのPR作成数は増えておらず、それどころかレビューの負荷が増えており、結果的に開発のリードタイムは長くなっていた」ことに気づくことができたのです。 「速く作る」だけでは限界がある 計測結果から見えてきたのは、「コードを書く速度が上がっても、ボトルネックがレビューに移り変わったために、全体のリードタイムは短くならなかった」、ということでした。 AIでコードを書くスピードは確かに上がります。一方で、内容を十分理解せずに生成するケースが増えると、PRの一貫性や正確性が落ちます。 指摘の量が増えると、リードクラスのレビュー時間が膨らみ、リードタイムが悪化します。最終的に、トータルのアウトプットはAI導入前とほぼ変わらない、という結果に着地します。 AIの成果物に対する確認や検証に時間がかかるようになり、レビューの負荷が増える。これがAI導入の落とし穴の一つです。そのため、AIの成果物の品質を再現性高く担保するための仕組みを整えることが必要になります。 そのために必要になるのが、「正しい作り方と手順」を仕組み化することです。馬を御する馬具（ハーネス）になぞらえ、AIの動きを暴走させず目的の方向へ導くための仕組みを整えることを ハーネスエンジニアリング と呼びます。 このハーネス化を、ファインディは 開発フロー改革 として進めてきました。具体的には、AI活用のレベルを3段階に分け、土台から段階的に積み上げていくロードマップを描いています。 AI活用レベル 開発フローを分解し、AIで何を肩代わりできるかをマッピングすると、3つのレベルが浮かび上がりました。 レベル 1：速く作る ：コード変更とPR作成を中心に、AIで代替できる範囲を自動化する レベル 2：正しく作る ：タスク分解とIssue作成までAIに任せ、「正しく作る」仕組みを整える レベル 3：必要なものを作る ：要件定義やQAという「AIで代替しづらい」とされてきた領域に踏み込む ポイントは、「どれか1つを単独でやる」のではなく、Lv1 → Lv2 → Lv3 と段階的に積み上げて初めて効果が出るという点です。ここから各レベルを順に見ていきます。 レベル 1：AIエージェントでコード生成 レベル 1の目的は、コード変更とPull request作成までをAIエージェントに任せ、人間は本質的なレビューに集中することです。 このフェーズで真っ先に向き合う必要があるのは、「AIが出したコードの責任は誰にあるか」という問いです。 どれだけ自動化されても、AIが出力したコードの責任は人間にあります。品質と判断の最終責任は人間が引き受けることになります。 その前提の上で、レベル 1の工程を整理してみました。 コード変更とPull request作成はAIに全て任せることが出来ます。そしてレビューに関しては、コードの責任という観点から人間が行う必要があると考えていました。しかし、本当にそうなのか疑問に思いました。 自分自身がコードを書いてPull requestを作成していた頃を思い出してみてください。自分でコードを書いて、Pull requestを作成する。レビュー依頼を出す前にやっていたことがありました。セルフレビューです。 そしてセルフレビューで気づく内容と、実際に他のメンバーからもらうレビューの内容は観点や内容が違います。これを今回の開発フロー改革に当てはめました。 レビューをセルフレビューとレビューに分け、レベル 1ではセルフレビューまでをAIに任せることにしました。セルフレビューではコード変更そのものに対するレビュー、レビューでは人間が最終判断しないといけない内容にフォーカスしてレビューというように切り分けることにしました。 ここで重要なのは、AIを入れる前提として「AIと関係なく当たり前のこと」が揃っている必要がある、という点です。 アーキテクチャ・命名規則・型定義といったコード設計、十分なテストカバレッジ、一貫した設計パターン、そしてPRの適切な粒度・レビュー文化・タスク分解の習慣。 これらはAI以前から品質を保つために必須でしたが、AIエージェントが入ると一気に効いてきます。土台が弱いと、AIはその弱さを増幅する方向に働くからです。 ファインディがこの「土台」をどう積み上げてきたかは、次の記事で詳述しています。 tech.findy.co.jp その土台の上に、AIが参照するドキュメントとルールをガードレールとして整備します。 READMEやプロジェクトドキュメントで開発前提・アーキテクチャ・運用ルールを記述し、AGENT.mdやrulesでコード規約・命名規則・テスト方針をAIに自動参照させ、カスタムコマンドやプロンプトテンプレートで依頼タスクを規格化する。 この整備があって初めて、AIは使い物になるコードを出力してくれます。 ファインディではレベル 1を支える仕組みとして、Claude CodeのSkillを複数組み合わせています。代表的なものは次の通りです。 Pull request作成：typecheck／lint／test／buildといった品質チェックの自動実行、ブランチ命名規則の強制、Conventional Commitに沿ったコミット生成、PRテンプレートからのbody自動生成までを1コマンドで実行 Pull request作成前の自動セルフレビュー：セキュリティ／コード品質／規約準拠／Simplify観点／要件検証／チェックリスト照合の6観点で並列分析。信頼度の高い指摘のみを報告してノイズを抑制し、2026年4月時点で1500以上のPRで運用中 AI併用レビュー：Codex CLIを別系統として並行運用し、メインAIのレビューと統合してPRコメントに提示。AIの偏りに依存しない複眼チェックを実現 定期セルフレビュー自動化：平日の朝方にGitHub Actionsで起動し、直近1ヶ月変更されていない技術的負債となりうる既存コードに対して修正Pull requestを自動作成 チェックリスト自動更新：過去レビューコメントをGitHub APIで収集し、LLMで指摘パターンを分類してチェックリストへ反映。レビュアーの暗黙知をSkillに形式知として残す セルフレビュー周りの仕組みについては、それぞれ次の記事でも紹介しています。 tech.findy.co.jp tech.findy.co.jp これらは1リポジトリにSkill／Sub Agent／MCPとしてまとめており、Pluginとして運用することで /plugin install によるワンコマンド配布を実現しています。全員がcontributeできる構造にすることで、改善がそのまま組織全体に反映される回り方になっています。 レベル 2：AIエージェントでモノを作る レベル 1で「速く作る」の足回りが整うと、次にぶつかるのが「要件をどう実現するか」の手順自体がAIフレンドリーではない、という壁です。タスクの粒度や手順を誰も明示的に決めていないため、生成AIに何を渡せば精度よく動くかが属人化していました。 ここで必要になるのが、「作りたいもの（What）」と「作り方の設計図（How）」を分離して扱う発想です。 Whatをタスク分解の形でHowに落とし込み、それをAIに渡せば、AIはそのステップどおりに実装してくれます。そしてレビューでは、出来上がったコードよりも先に「作り方と実現方法が合っているか」を検証し、設計図のほうにフィードバックする。タスク分解の品質が、そのままアウトプットの品質を決める構造です。 このフェーズでは、AIとの関係性が「協働」から「委任」に変わります。 Vibe Codingが「AIは隣で並走するパートナー」だとすると、Agentic Workflowは「AIは自走する実行エージェントで、人間はその指揮者」になります。 任せる粒度も、1行〜1関数のレベルから、タスク／PR／フロー全体へと拡張されます。 Agentic Workflowの定義として4つの自律性を意識しています。 ゴール指向 ：「何を」を与え、「どう実現するか」はAIが組み立てる 計画と分解 ：大きなタスクをサブタスクに分けて順序付けて実行 ツール使用 ：ファイル・Skill・コマンド・検索・MCPを能動的に使う 自己検証ループ ：テスト失敗→修正→再実行を自律的に繰り返す 興味深かったのは、AI委任の前提が変わると開発環境そのものが変わったことです。 2026年に入ってから、ファインディではコード生成のメインツールがIDEからターミナルへ変化しました。 1ウインドウで1タスクずつ進めるのではなく、複数ウインドウ・ペインで同時にAIへ委任するスタイルになったため、並列委任しやすい場所として、ターミナル＋tmuxのような構成に自然と寄せていく流れになっています。IDEの役割はコードを書く場から、広域に渡るコードリーディングや理解を深める場へとシフトしています。 このレベル 2を支えるのが、要件構造化＆Issue自動生成のSkillです。次の6ステップで動きます。 要件理解 ─ インタラクティブな質問で曖昧さを解消 コード探索 ─ 並列の探索Agentが複数観点で同時調査 要件明確化 ─ 不足情報を補完してスコープを定義 設計提案 ─ 実装方針のドラフトを生成 タスク分解 ─ 実装単位に分解（粒度判定Skill連携） Issue作成 ─ Sub Issue／relationshipを含む構造化Issue このSkillで生成したIssueは累計3000以上にのぼり、親Issue（Feature）→子Issue（DB層→API層など）が blocked_by の依存関係付きで自動構成されます。 例えば「ユーザー通知機能の追加」という親Issueに対し、「#1 DB層：通知テーブル追加」「#2 POST API追加」「#3 DELETE API追加」のような子Issueが、依存関係込みで一気に並ぶイメージです。 実装フェーズでは、これを「Issue × Worktree × Agent」の並列モデルで走らせています。Team Lead Agentが blocked_by に従ってLayerごとにWorker Agentを起動・同期し、同じLayer内はworktreeを切ってWorker Agentが完全並列で実装する。Layer 0でDB層が完了したら、Layer 1のPOST／DELETE APIを2つのworktreeで同時に進める、といった動かし方ができます。 この並列モデルの詳細は次の記事で解説しています。 tech.findy.co.jp コードレビューの分担も、レベル 2では明示的に再定義しています。 担当 レビュー領域 AI コード規約・命名、型定義、テストコード・テストケース 人間 ビジネスロジックの要件適合、アーキテクチャや設計、データベース構造、明確なセキュリティリスク 視点はコードそのものから抽象的なところに寄せていきます。 結果として、レベル 2の導入後、1人あたりのPR作成数は前年比で1.5倍を超えました。AIフレンドリーな「設計図（タスク分解＋構造化Issue）」を誰でも作れる状態になり、作りたいものを再現性高くアウトプットできるようになった、というのがその答えです。 レベル 3：AIで価値を生み出す レベル 2まで進むと、開発スピードに対する次のボトルネックが見えてきます。「何を作るか」の上流が詰まり、せっかく整えた実装力を活かしきれない状態です。 具体的には、要件の実現可能性を調査できるのがエンジニアだけになっていたり、システムとプロダクトの概念が離れていて、お互いを十分知らないまま施策や検証が進んでしまったりします。 レベル 3の目的は、要件定義（PdM領域）とQA領域というAIで代替しづらいとされてきた領域に、AIで踏み込むことです。 レベル 3の起点になるのが 現状把握 です。現状把握の対象は広い範囲に及びます。コードベース・Google Analytics・プロダクト文書・GitHub Issues／PR・Datadog・各種KPIなど、必要なコンテキストは多岐にわたります。 まず要件定義では、これらを毎回手動で集めるのは現実的ではないため、専門Agentチームが各ソースから必要な分だけ自動収集する仕組みを組みました。 ファインディの要件定義Skillでは、7つの専門Agentが並列で動きます。 目的・成果分析 ─ WHY／WHAT仮説の自律生成 データ・コンテキスト収集 ─ GitHub Issues・Notionから数値収集 プロダクト文書抽出 ─ docs／配下のKPI・ポリシーを抽出 コードベース分析 ─ リポジトリの制約・パターンを分析 スコープ分割 ─ MVPと拡張項目に分割 技術的実現可能性評価 ─ 解決アプローチの実現可能性を評価 アクセス解析データ収集 ─ Google Analyticsから自動収集 これらのAgentがAgentTeamsとして並列で稼働し、お互い会話しながら必要な情報を集めて分析します。 ユーザーは分析結果を修正・補足し、最後にAIが構造化＆品質チェックしてGitHub Issueとして出力します。ユーザー操作は入力・レビュー・承認の3回のみで、それ以外はAIが自律的に進める設計です。出力されたWHY／WHAT構造化済みIssueは、そのままレベル 2のIssue自動分解Skillに連携できます。 もう1つの挑戦がQA領域です。ユーザビリティ・アクセシビリティ・UI／UXといった非機能要件のテストはAI単独では難しいため、AIで代替しづらい領域です。ファインディは「代替」ではなく「支援」、つまりAIがQAエンジニアの判断を最大化する形を仮説にしています。 次にQA領域は3つのSkillで一気通貫にしました。仕様ソース（Issue／Figma／Notion）を入力に、次の流れで進みます。 QA観点抽出：観点を自動抽出してQA観点mdを出力 QAテストケース生成：観点→ステップ／期待結果／前提条件に展開してMarkdown＋CSV化 QA自動実行：Playwright MCP経由でClaude Codeから直接ブラウザを操作し、Pass／Failとスクリーンショット付きのレポートを出力 QA観点抽出では、仕様分析／画面構造・UX探索／影響範囲判定の3つのAgentが並列で動き、観点設計のたたき台を数分で生成します。 テストケース生成では、観点→具体ケースへの落とし込みにかかる工数が数時間から数分に短縮されました。生成されたQAリストは、認証・認可／入力バリデーション／表示・UI／ファイル操作／外部連携／メール送信の6軸で共通基準と照合し、観点漏れ・粒度のばらつきを検出します。 人間が集中すべきは、ユーザビリティ評価、例外シナリオ、クライアント要件の確認といった「判断が必要な領域」です。反復可能なケースはAIが淡々と実行し、失敗時はスクリーンショット付きレポートで原因特定が速くなりました。 まとめ AI活用のレベルをレベル 1（速く作る）／レベル 2（正しく作る）／レベル 3（必要なものを作る）と分けてきましたが、最大の主張は、これらは「どれか1つ」ではなく段階的に積み上げて初めて成立する、ということです。 そして、ここで強調したいのが 順番を間違えない ことです。土台が弱いと、ガードレールもAI Skillも成果を出せません。ファインディが踏んだ順番は次の4段でした。 裏返すと、AIエージェントを入れる前にやっておくべきことは、AI以前から変わっていません。統一規約、テストコード、PR粒度、レビューなどの開発文化といった 基本の徹底 こそがAI活用における大前提です。 AI時代の本丸は、「速く作る」ではなく、「正しく作る」「必要なものを作る」への段階的越境です。あなたの組織が今どのレベルにいるか、そして次のレベルへ進むためにどの土台が弱いかを確認する目安として、このロードマップが役立てば幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

G-gen の武井です。当記事は Google Cloud Next '26 in Las Vegas のブレイクアウトセッション「 One tool to rule them all: Extending and customizing the Gemini CLI 」について、速報レポートをお届けします。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 AI 開発ツールが抱える 3 つの課題 Gemini CLI と拡張ポイント Gemini CLI とは 拡張ポイントの全体像 John のジャーニーで見る Gemini CLI 拡張デモ 1. 組み込みツールによるコードベースの探索 2. Agent Skills で専門知識をパッケージ化する 3. Sub-agents でコンテキストを分離する 4. Extensions でカスタマイズをチームに共有する Extensions Gallery によるコミュニティ連携 セッションの概要 本セッションでは、ターミナル上で動作する AI エージェント Gemini CLI を、開発者個人のワークフローに合わせてカスタマイズし、さらにそのカスタマイズをチームやコミュニティへ共有するための拡張ポイント（Agent Skills、Sub-agents、Hooks、Extensions）について解説していました。 登壇者は Google Cloud の Aishanee Shah 氏と Abhi Patel 氏の2名です。座学だけでなく、John という架空の開発者が Gemini CLI のコードベースをキャッチアップし、得られた知見を共有可能なパッケージにまでまとめ上げるジャーニーを題材に、ライブデモを交えて段階的に紹介する構成です。 参考 : Gemini CLI - Google Cloud Gemini CLI の詳細な解説については、以下の記事を参照してください。 blog.g-gen.co.jp AI 開発ツールが抱える 3 つの課題 近年の AI モデルはコーディング、コードベース探索、リサーチに非常に強くなった一方、その周辺ツール（Web 上の AI チャット、IDE、CLI ツールなど）が急増した結果、開発者がそれらの間を伝書鳩（messenger pigeons）のようにつないでいる現状が指摘されました。 Abhi 氏自身、Chrome チームに在籍していた頃、エラーやスタックトレースを Web の Gemini チャットへコピー＆ペーストし、結果をまた IDE に戻す、という非効率な作業に多くの時間を費やしていたとのことです。 セッションでは、こうした現状から派生する課題が 3 つに整理されていました。 1つ目は テクノロジーの孤島 （tech islands）です。Web アプリ、IDE、CLI ツールが乱立しているなかで、それらをいかに効果的に組み合わせるかという問題を指します。 2つ目は 認知的過負荷 （cognitive overload）です。プロンプトの構造設計や適切なコンテキストの収集を、ユーザー側が常に意識しながら組み立てる必要があるという課題です。 3つ目は 車輪の再発明 （reinventing the wheel）です。完璧なプロンプトやワークフローを構築できたとしても、それをチームや組織全体で共有・再利用する手段がなければ、各々が同じ努力を繰り返すことになります。 これらの課題を解決する鍵として、複数のツールとコンテキストを束ねる オーケストレーター が必要であり、その役割を担うのが Gemini CLI である、というのがセッションの出発点として提示されました。 Gemini CLI と拡張ポイント Gemini CLI とは Gemini CLI は、ターミナル上で動作するオープンソースの AI エージェントです。最先端の Gemini モデルへの軽量かつ直接的なアクセスを提供し、開発者が指定したゴールに向けてコンテキストを収集・維持しながらタスクを実行します。詳細は以下を参照してください。 参考 : Gemini CLI - Google Cloud 参考 : Gemini CLIを解説 - G-gen Tech Blog 拡張ポイントの全体像 セッションでは、Gemini CLI を自分のワークフローに合わせて深くカスタマイズする手段として、以下 4 つの拡張ポイントが紹介されました。 Agent Skills （エージェントスキル） : 専門知識・手続きワークフロー・関連リソースをひとまとめにしたモジュール Sub-agents （サブエージェント） : 特定タスクに特化した独立エージェント。コンテキストとツール選択をメインエージェントから分離する Hooks （フック） : エージェントのライフサイクル上の任意のタイミングに介入するための設定可能なポイント Extensions （エクステンション） : Skills、Sub-agents、Hooks、コマンド、MCP サーバー、コンテキストファイルなどを 1 つの共有可能なパッケージにまとめる仕組み Aishanee 氏は「2026 年の開発者は、こうしたカスタマイズの作り込みとメタワークフローの構築に多くの時間を使っている」と述べ、AI 時代の開発者の作業の重心が、自らコードを書くことから、エージェントツール群の設計・編成へとシフトしていることを強調していました。 John のジャーニーで見る Gemini CLI 拡張デモ 1. 組み込みツールによるコードベースの探索 John はまず、Gemini CLI のリポジトリをクローンしたうえで、ターミナルから Gemini CLI を起動し、自然言語で「サブエージェントの委譲（sub-agent delegation）がどう動くのか理解したい」と尋ねます。 ここで Gemini CLI は 思考モード （thinking mode）に入り、組み込みツールを使って必要なファイルを段階的に読み込みます。1つ目のファイルを読んで把握、必要な情報を絞り込んで次のファイルを読む、という形で探索を進め、最終的に Markdown 形式の要約を返しました。 John は視覚的に理解したいタイプなので、続けて「フローチャートに変換して」と依頼します。すでに直前の探索で十分なコンテキストを集めているため、追加のファイル読み込みなしに、ターミナル内に ASCII アートのフローチャートが描画されました。 ここまでが、 組み込みツールだけで実現できる「単発の探索」 です。一度きりのコードリーディングや、ざっと全体像をつかみたい場面には十分強力ですが、生成された図をチームメイトと共有したい・設計ドキュメントに貼り付けたい、といった次の段階には不向きです。 2. Agent Skills で専門知識をパッケージ化する そこで登場するのが Agent Skills （エージェントスキル）です。Agent Skills は、専門知識・ワークフロー・スクリプトをまとめたモジュール式の自己完結パッケージで、エージェント向けの作業手順書のような位置づけのものです。Agent Skills の構造は単純で、以下のようなディレクトリで成り立ちます。 skill.md : 必須ファイル。YAML フロントマターでスキルの name と description を定義し、Markdown 本文にエージェントへの指示を記述する references/ : 補助的な参考資料を置く任意ディレクトリ scripts/ : 検証や変換などに使うスクリプトを置く任意ディレクトリ 特に重要なのは skill.md の description フィールドです。これは カタログ上の説明文 として機能し、メインエージェントは多数のスキルの中からこの description を読んでどれを呼び出すか判断します。 スキルが実際に呼び出されたタイミングではじめて、Markdown 本文の指示や参照ファイルの中身がコンテキストにロードされる仕組みです。これによりメインエージェントのコンテキストを過剰に汚染することなく、必要な専門知識を ジャストインタイム で投入できる点が肝になります。 デモでは、John があらかじめ用意していた Mermaid 作図用のスキルを、Gemini CLI に再ロードさせて使用します。直前の探索で集めたコンテキストはセッションに残っているので、John が「Mermaid の図を作って」と指示するだけで、エージェントはカタログから Mermaid スキルを発見・起動し、ファイルを生成しました。 ここで興味深いのが、Mermaid スキルには png ファイルへの変換スクリプトと生成されたファイルが破損していないかを検証するスクリプトまでバンドルされていた点です。スキル単体で Mermaid ソースの生成 > png ファイルへの変換 > 検証 までを完結させており、最終的には共有可能な2つのファイルを得ることができました。 Aishanee 氏はこの設計について、 自分がすでに解いた問題に毎回トークンを消費させるのではなく、一度作って・バンドルして・再利用する という思想を強調していました。 3. Sub-agents でコンテキストを分離する スキルは強力ですが、ワークフローが長く・複雑になるにつれて限界も見えてきます。スキルを呼び出すたびに、その参照ファイルや手順がメインエージェントのコンテキスト（記憶）に挿入されるため、複数のスキルをまたぐ作業では情報が断片化し、過負荷に陥ってしまうのです。たとえば「Mermaid 図の生成と検証」のような専門タスクの細部がノイズとなり、本来の目的である探索タスクの邪魔をしかねません。 そこで真価を発揮するのが Sub-agents （サブエージェント）です。 サブエージェントは、特定のタスクに専念する独立したエージェントです。メインエージェントとは明確に分離された「独自のコンテキスト」と「専用のツールセット」を持ちます。タスクが完了すると、サブエージェントは「最終結果」と「次に繋がる最も価値の高い情報」だけを抽出してメインエージェントに返却します。これにより、 メインのセッションを常にクリーンな状態に保つ ことができます。 サブエージェントを構成する中核要素は、特定の役割を与える「 ペルソナ （システムプロンプト）」と、それに最適化された「 ツールセット 」の2つです。Abhi 氏も紹介しているように、CLI には組み込みのサブエージェントとして Codebase Investigator などが用意されています。これは、新機能の調査時などに発生する「長大なコードベースの探索」という重い処理を、メインの思考プロセスから切り離し、独立したコンテキストに閉じ込めるために生まれたものです。 カスタムサブエージェントにはローカル型とリモート型の2種類があります。ローカル型は Gemini CLI の組み込みツール（read、grep、skills など）を直接利用するもので、リモート型は A2A プロトコルに対応した既存エージェントへ接続するもので、クラウド側のエージェントを呼び出す用途に有効です。 サブエージェントの定義ファイルは、設定を記述するフロントマター（YAML 形式など）と、システム指示を記述する Markdown 本文から構成されます。フロントマターには name、description、tools（許可するツールのリスト）、model（使用するLLM）などを定義します。 ここで最も重要なのが description の質 です。メインエージェントは、この説明文を頼りに「 暗黙的な呼び出し （Implicit invocation）」を行います。説明が貧弱だと、メインエージェントは「いつ、どのタスクを委譲すべきか」を正しく判断できないため、役割と発動条件を明確に記述することがサブエージェントを使いこなす最大の肝となります。 また、サブエージェントごとにツールを厳格に制限できるのも大きな利点です。例えば「Codebase Investigator」では、ファイルを意図せず書き換えないよう、許可ツールを読み取り系（Read-only）のみに絞り込んでいます。 さらに発展的な設計として、サブエージェントの定義内に MCP（Model Context Protocol）サーバーをインライン化することも可能です。たとえば、50を超える機能を持つ Google Workspace の MCP ツール群を特定のサブエージェント内に閉じ込めることで、メインエージェントのコンテキストを汚染せずに高度な外部連携を実現できます。Abhi 氏はこのアーキテクチャの利点を「メインエージェントを context rot （コンテキストの腐敗。不要な情報やツールによってコンテキストが劣化すること）から守る手段」と強調していました。 デモでは、John が Mermaid スキルとアーキテクチャ図作成を1つにまとめた architect-visualizer というサブエージェントを事前に作成しておき、 @architect-visualizer のように @ 構文で呼び出していました。 新規セッションから始めても、サブエージェントは自身のシステム指示に従って Mermaid スキルをアクティブにし、必要に応じて何度もコードベースを読み返しながら 正確性を担保するためのダブルチェック を行います。これらのファイル読み込みはサブエージェントのコンテキストに閉じ込められ、メインエージェントには ASCII の図と最終ファイルの場所だけが返却されました。 4. Extensions でカスタマイズをチームに共有する ここまでで作成した Skills と Sub-agents は、いまだ John の手元のローカルにあるだけです。チームに展開し、社内全体で再利用するためには Extensions （拡張機能）でパッケージ化します。 Extensions は、Skills、Sub-agents、Hooks、コマンド、MCP サーバー、コンテキストファイル（ gemini.md 、 claude.md 、 agents.md など）を一括で 1 つの共有可能なディレクトリにまとめる仕組みです。最低限、以下が揃っていれば成立します。 gemini-extensions.json （マニフェストファイル） 共有したい Skills / Sub-agents / Hooks / コマンド / MCP サーバーの定義 エージェント側に「いつ・どう使うか」を伝えるためのコンテキストファイル なお Hooks は、エージェントのライフサイクルにおける任意の介入ポイントを設定する仕組みで、Google 社内でも独自機能を解放する目的で使用されているとのことでした。 ドキュメントを読み込んでマニフェストを手書きするのは煩雑です。そこでデモでは、Gemini CLI に同梱されている組み込みサブエージェント cli_help agent を @ 構文で呼び出し、対話的に Extension を組み立てるという画期的なアプローチが紹介されました。 cli_help agent は、ドキュメントを参照してマニフェスト構造を理解した上で、組み込みの ask user ツール（ユーザーに質問を投げかける機能）を使用します。これにより、「どんな拡張機能を作るか」「どのスキルを含めるか」「どのサブエージェントから呼び出すか」を順番に確認してくれます。 ユーザー（John）は、「Mermaid スキルとアーキテクチャ図のサブエージェントを含む architecture-visualizer 拡張を作りたい」といった自然言語で答えるだけでよく、必要な JSON やコンテキストファイルはすべて自動で生成されました。 完成した Extension の配布方法は、ユースケースに応じて使い分けられます。誰でも利用できる形で公開する場合は、パブリックな Git リポジトリで配布します。一方、機密性の高いプロンプトや MCP サーバーを社内限定で配布したい場合は、プライベートリポジトリやローカル共有フォルダを使った セキュアディストリビューション を取ります。Abhi 氏は、Google 社内では各チームが独自の Extension を作成し、それを社内に広く共有する文化が根付いていると紹介していました。 Extensions Gallery によるコミュニティ連携 最後に紹介されたのが、コミュニティ全体で Extension を発見・共有できる Extensions Gallery です。2026年4月現在、数百規模の Extension が公開されており、Googler が開発した BigQuery や Google Workspace の Extensions から、サードパーティ企業が自社製品向けに公開している Extensions まで、幅広く利用できます。 ここで強調されていたのは、ギャラリー内の各 Extensions も、本セッションで紹介された仕組みの組み合わせに過ぎないという点でした。同じ部品を組み合わせて掛け算的にスケールさせ、コミュニティ全体で共有していく、というのが Gemini CLI の Extensions の構想の本質と言えそうです。 参考 : Extensions - Gemini CLI 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei