はじめに 　レバレジーズ株式会社 テクノロジー戦略室 SRE チームの中野です。レバレジーズでは「SRE 化を通して、Developer Experience の改善、事業の拡大への対応、お客様に信頼されるサービスの提供を実現する」をミッションとして、サービス改善の文化的土俵の構築や開発生産性の向上を進めています。 　過去記事 (= Terraform による IaC の標準化を通じた、全社規模の開発体験の向上への取り組み ) では、社内標準となる IaC ツールの選定と、IaC 化の作業負荷の軽減を狙ったライブラリ・テンプレートの作成についてご紹介しました。 　今回はその続編として、これらの製品を Template as a Service として提供する中で見えてきたユーザペインと、AI Agent Skills によるペインの解消・製品強化の取り組み、そして今後の展望についてご紹介します。 　現在、SRE・Platform Engineering の取り組みで Template as a Service を社内展開しているが、製品を使いこなすまでのハードルが高く製品普及が思う様に進まない。この様なペインを抱える開発組織の参考になれば幸いです。 　なお、本記事で紹介する取り組みは、2026年4月開催の AWS Container Platform Engineering Meetup のパネルディスカッションでご紹介した話の詳細版です。当日話し切れなかった部分を本記事でお伝え出来ればと思います。 背景 　現在は、下表の Template as a Service を提供中です。初めにインフラ作業の効率化・省力化を狙って Terraform Modules、GitHub Composite Actions、GitHub Repository Template を作成し、学習による知識強化も狙って Terraform Handson というハンズオン形式の学習教材も作成しました。これらの製品により、IaC 化推進の環境を整えてきました。 提供製品 概要 Terraform Modules (AWS Provider 向け) ELB・ECS・RDS 等の単体リソースに対応する Component Modules、CloudFront・WAF 等の複数のリソース群を組み合わせた Catalog Modules の2種類がある GitHub Composite Actions Terraform 用の CI/CD、アプリ用の CI/CD 等の共通処理をパッケージ化したものが多い GitHub Repository Template (Terraform 向け) Terraform Backend の環境構築、CI/CD 用の IAM リソース設定、Slack 関連設定、アラート用のリソース設定等の手順・設定を同梱しており、IaC 導入時の初期作業を低工数で済ませられる Terraform Handson Terraform 用のハンズオン教材であり、Terraform の基礎から発展までを短期間で学習出来る 　一方、製品利用が進むにつれて、製品の改善点が見え始めました。以下は、ヒアリングやフィードバックを通して得られた代表的なペインです。 　当初は Embedded SRE 等の手慣れたエンジニアを対象に製品のファンを増やすことを目的としていましたが、今後のユーザ拡大を考えると、ペインを解消して製品の使い勝手を強化することを優先すべきだと考えました。 Terraform Modules モジュールの使い方や必要な変数の組み合わせが、仕様や利用例だけでは判断しにくい モジュール毎の使い分け基準は書かれているが、どのモジュールを使うかの判断が難しい GitHub Repository Template 初期整備の手順資料・作業工程が多く、作業全体の流れや進捗を把握しにくい 設定項目が多く、必須なものが分からないため、何を埋めるべきか判断しにくい AI の活用方針の検討 　社内では AI Agent の利用が広がっており、これを活用すれば作成コストを抑えながらペインを十分に解消可能だと考えました。実際、社内要件・命名規則やクラウドのベストプラクティスに沿って提供製品が作り込まれており、AI による代行が十分に可能でした。そこで、AI Agent Skills の作成を決めました。 　次に、先述のペインを起点に Skill で解決可能なことを整理して製品案を考え出し、次の基準をもとに作成優先度を決めました。その結果、下表の「Terraform コード生成 Skill」及び「GitHub Repository Template の初期整備 Skill」を高優先で作成すべきだと判断し、これらの作成から始めることにしました。 作成優先度の決定基準 ペインの程度や発生頻度 負荷・コスト等の削減効果 直近の利用予定、社内要望 作成候補の優先度一覧 作成候補 優先度 対象者 判断理由 コード生成 Skill 高 ユーザ Terraform コードの実装・修正が他の作業よりも高頻度である 初期整備 Skill (GitHub Repository Template 用) 高 ユーザ IaC 関連の初期作業のみの利用だが、自動化の効果が大きい スタイルガイド Skill、 製品仕様ガイド Skill 中 ユーザ 運用フェーズでの実装・仕様把握の負荷を継続的に下げられる モジュール開発 Skill、 コードレビュー Skill 中 メンテナー 開発・レビューの作業負荷を下げ、省力化・体制分散に繋がる Terraform Ops Skill、 コスト試算 Skill、 インフラ構成図 Skill 低 ユーザ、メンテナー 発生頻度・現在の負荷が比較的小さく、将来の開発対象とする AI Agent Skills の作成 　ここでは、高優先で作成した「Terraform コード生成 Skill」及び「GitHub Repository Template の初期整備 Skill」の概要・ワークフローや設計・工夫についてご紹介します。 　前者は Terraform Modules の「使い方・使い分けの判断が難しい」というペインに、後者は GitHub Repository Template の「初期整備の工程が多く進捗や設定値の判断が難しい」というペインに、それぞれ対応するものです。 Terraform コード生成 Skill (AWS / Google Cloud) 概要・ワークフロー 　Terraform コード生成 Skill とは、ユーザへのヒアリングに基づいて Terraform コードを生成する Skill です。AWS・Google Cloud の Provider 毎に Remote Skill (= terraform-codegen-aws / terraform-codegen-google ) として提供しており、EC2・RDS 等の単体サービスから、静的サイト (CloudFront・WAF・S3) や Web システム (ALB・ECS・RDS 等) といったインフラ構成のコードまで生成出来ます。処理フローは次の通りです。 No ステップ 概要 1 ユーザへのヒアリング サービス名・環境名・リージョン等の要件情報を聞き出し、必要なインフラリソースを洗い出した上でリソース設定の追加確認を行う 2 Terraform コードの生成 ヒアリング結果に基づき、必要なインフラリソースに関する Terraform コードを生成し、実行場所にコードを書き込む 3 Terraform コードの検証 生成したコードに対して terraform fmt/validate のコマンドを実行し、エラーが無くなるまで検証・修正のサイクルを繰り返す 4 完了報告と追加確認 設定の判断理由を含めて作業結果を報告し、コードの追加・修正の要望を確認する 　ヒアリングでは、推測可能な情報は聞かないことを原則として、要件等の推測が難しい情報だけを AI Agent がユーザへ確認します。また、どのリソース・モジュールを用いるか、変数設定をどう組み合わせるか等のコード生成に必要な判断を AI Agent が担います。この様な設計により、ユーザの確認負荷を抑えています。 　コード生成では、下記の優先順位で生成方法を選択します。terraform-codegen-aws は、該当する社内向け Terraform Modules があれば必ず利用し、無い場合はモジュールを用いずに生成します。一方、terraform-codegen-google は、社内向け Terraform Modules を提供していないため、モジュールを用いない生成を基本としています。 　なお、Public Modules の利用については、両方の Skill に共通で、バージョン更新時の追従負荷を考慮して要望があった場合のみ利用可能なオプションとしています。 terraform-codegen-aws の生成方法の優先度 (a) 社内向け Terraform Modules を利用する (b) モジュールを用いずにコードを生成する (c) Public Modules を利用する (要望時のみ) terraform-codegen-google の生成方法の優先度 (a) モジュールを用いずにコードを生成する (b) Public Modules を利用する (要望時のみ) 　この優先順位には、社内標準の資産を AI のコード生成経路そのものに組み込む狙いがあります。ユーザが社内モジュールの存在や使い分けを知らなくても、生成されるコードは自然と社内標準に沿ったものになり、個々のエンジニアの習熟度に依存していた社内標準への準拠を仕組みの側で担保出来ます。 設計・管理のポイント 　各々の Terraform コード生成 Skill に共通する設計・方針の枠組み (= SSoT の管理方針、検証の実施方針等) を定めており、これに基づいて各 Skill が作り込まれています。 　まず、Skill では SSoT の管理方針を明確に決めています。モジュールの仕様・バージョン等は外部情報として Skill 内で持たずに CLI コマンドで取得し、ヒアリングの進め方・コーディング規約・組織固有の情報等は Skill 内で参照情報やテンプレートとして管理します。この方針で外部情報の更新への Skill の追従が最小限になり、Skill の管理・運用のコストを抑えられました。 　また、参照情報を取得出来なかった場合に AI が推測で値を埋めることを禁止しており、ユーザへの確認に基づくコード修正かプレースホルダの残置に必ず倒す設計としています。 　コード検証では、 terraform plan の実行を意図的にスコープ外としています。コード生成の段階では静的なコード検証さえパスすれば問題無く、クラウド上での検証までスコープを広げると検証が複雑になり、副作用のリスクが生まれると考えたからです。そのため、 terraform fmt/validate の実行によるコード検証として設計しています。 動作検証時の挙動改善 　動作検証で、簡単なコード生成でも一律に時間・トークンを大きく消費するという挙動面の課題が判明しました。実測したところ、主な原因は「参照情報を何度も取得しに行っていること」及び「簡単なコード生成でも複雑な手順で処理していること」にあり、次の改善を行いました。 　これらを「修正、検証、品質チェック」の処理サイクルで適用したところ、ユーザの入力・待機等を除いた処理自体の所要時間やトークン消費を、改善前よりも 30% 〜 40% 程度削減出来ました。 参照情報の取得方法の見直し 参照の度に発生していた取得処理を、最初に一括で取得・保存する方式に変更した 参照情報の取得の繰り返しを防ぎつつ、必要な情報を適切・十分に参照可能にした 生成内容に応じた処理の使い分け コード生成の進め方に応じた処理群のパターン分けを、生成モードとは別に設けた 生成処理の複雑さに応じて処理パターンを当てはめ、適切な処理をさせる様にした 機械的なチェックへの移行 文章ルールに基づくチェックを、スクリプトを用いたチェック処理に置き換え、照合のやり取りを削減した チェックルールは機械可読な一覧表で管理し、ルールの追加・変更が表の編集だけで済む様にした AI モデルの能力や実行毎のばらつきに品質が左右されにくくなり、安定化に繋がった GitHub Repository Template の初期整備 Skill 概要・ワークフロー 　初期整備 Skill は、Terraform 向け GitHub Repository Template から作成した GitHub Repository の初期整備を AI Agent が代行する Skill です。現在提供中の4種類の Repository Template に Local Skill (= terraform-repo-init ) として導入しており、Repository の作成後に Skill を発動するだけで初期整備を簡単に進められます。 　この Skill により、人間が対応すべき箇所は「ヒアリングへの応答、残りの限られた手動作業の消化」だけに絞られ、その他の作業を AI Agent が代行してくれます。手順書に沿った作業で起きがちなミスも、スクリプトを用いた機械的なチェックにより極力発生しない様にしています。処理フローは次の通りです。 No ステップ 概要 1 ユーザへのヒアリング 構成・仕組みの要否 (= 開発環境、定期チェック、通知設定) や設定値等の初期整備で決めるべき情報を冒頭で一括して確認する 2 クラウド認証の確認・実施 実行環境やクラウド認証の状態を確認し、未認証だった場合に認証コマンドを実行する 3 初期整備の自動実行 雛形の削除、テンプレート情報の置換、Terraform Backend の環境構築、GitHub Repository Secrets の登録、CI/CD の有効化、作業のセルフチェック等の自動化可能な作業を実行し、GitHub PR の作成まで進める 4 残作業リストの出力 実行するだけで済む様な文面・スクリプト等を用意した上で、残りの手動作業に関するチェックリストを出力して終了する 設計・管理のポイント 　Repository の初期整備には、自動化が難しい作業 (= 外部への依頼・承認等) や、統制の観点から人間が担うべき作業 (= 秘匿情報の設定、PR のマージ判断等) が含まれます。そこでまず、AI Agent とユーザの作業分担を明確に定めました。 　具体的には、環境検証・テンプレート置換・Backend 構築・Secrets 登録・PR 作成までを AI Agent が実行し、それ以外の作業は意図的に人間側に残しています。この線引きが、AI による作業代行を安心して組織展開するための前提だと考えています。 　この分担を前提に、自動化可能な作業を先に進めて手動作業を最後にまとめる形へ作業全体の流れ・手順資料を再整理し、初期整備の自動実行とユーザへの残作業の提示を AI Agent に行わせる Skill を作りました。どの工程でも開始時に完了状態・前提条件・スキップ条件等を確認してから進行させる様になっており、途中で中断した場合でも安全に再開出来ます。 　なお、コード生成 Skill と同様に SSoT の管理方針も定めています。手順・コマンド等の具体値は Repository Template の資料・スクリプトを SSoT として参照し、Skill 自体は判断ロジックと工程の順序のみを持つ構成としています。 Skills の管理・配布 　Terraform コード生成 Skill は、特定の GitHub Repository に依存しない用途のため、Skill 専用の GitHub Repository で Remote Skill として管理しています。一方、GitHub Repository Template 用の初期整備 Skill は、Template 内の手順資料・スクリプトと一体で動く用途のため、Template 内で Local Skill として管理しています。 　配布についても、管理方式に合わせて分けています。Terraform コード生成 Skill は GitHub CLI コマンド ( gh skill install ) で利用可能にしており、GitHub Copilot・Claude Code 等の AI Agent 間の仕様差異を GitHub CLI が吸収してくれるため、統一的な手順で配布出来ます。初期整備 Skill は、Template から Repository を作成した時点でそのまま利用可能なため、配布作業が不要です。 今後の展望 　今後は、作成候補の優先度一覧で中優先以下とした Skill を順次作成し、ユーザ向けのインフラ作業のペイン解消だけでなく、製品メンテナーの開発・改善における作業負荷の軽減にも AI を活用していく予定です。これにより、Template as a Service の提供サイクルを現在の開発体制でも十分に回せる様に強化したいと考えています。 　過去記事では「Template as a Service を作り、IaC 化を推進する」をご紹介しました。今回は「AI Agent が Template as a Service を使いこなし、エンジニアの代わりに作業する」への進化をご紹介しました。Template as a Service × AI の組み合わせで、AI を前提としたゴールデンパスを引き続き提供し、利用の障壁の無いプラットフォームへと育てていきます。 最後に 　レバレジーズでは、全社の SRE・プラットフォームエンジニアリングの推進に向けて、開発生産性の向上に一緒に取り組んでいただけるエンジニアを募集しています。 　SRE の文化・体制に興味があったり創っていきたい方や、プラットフォームエンジニアリングの実践による開発生産性の向上に興味がある方は、是非ともご応募をお待ちしております。

こんにちは。ファインディ株式会社でプリンシパルエンジニアをしている戸田です。 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

はじめに こんにちは、同志社大学理工学部情報システムデザイン学科4年生の金谷一輝です。 2026年7 ...