AI駆動開発がもたらすパラダイムシフト

Copyright © POSTAS CO., LTd. All Rights Reserved. S ポスタス株式会社
S ミイダスさん社内勉強会「AI駆動開発がもたらすパラダイムシフト」坂本涼輔 2026/3/15

Copyright © POSTAS CO., LTd. All Rights Reserved. S S
1. はじめに 2026/3/13 p2 一切手を動かすことなく、プロジェクトが完結する。そんな開発体験に興味はありませんか？

1. はじめに 2026/3/13 p3 それを実現するのが、 Agentic Workflow

2. まずはAI駆動開発を知る 2026/3/13 p4 全ての開発工程においてAIエージェントを主体とし、人間は方針決定・コンテキストの提供・レビューのみに専念する開発アプローチ • AI駆動開発とは • AI駆動開発の目的開発工程においてAIを利用することにより、従来のクオリティを担保した上で開発スピードを向上させること。

3. AI駆動開発には3つの段階がある 2026/3/13 p5 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30%

3. AI駆動開発には3つの段階がある 2026/3/13 p6 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30% AIツールの基本的な機能を使いこなせるレベル。用途に応じてモデルを使い分ける、適切にトークン管理ができる、エージェントを複数稼働させるなど。

3. AI駆動開発には3つの段階がある 2026/3/13 p7 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30% Vibe Codingのように要望を投げるだけでなく、どんな前提で・どのルールに従って・何を基準に良しとするかまで含めてAIに指示できるレベル。

3. AI駆動開発には3つの段階がある 2026/3/13 p8 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30% 「AIが与えられた目標に対し、自律的に計画を立て、タスクを実行する一連の作業プロセス」をワークフローとして人間が設計できるレベル。

4. AI駆動開発は全ての開発工程が対象となる 2026/3/13 p9 要件定義単体テスト実装基本設計詳細設計システムテスト統合テスト AI 50% 人 50% AI 60% 人 40% AI 70% 人 30% AI 80% 人 20% AI 70% 人 30% AI 60% 人 40% AI 50% 人 50% 全ての開発工程の主体をAIエージェントに移すことができる。全ての開発工程でAgentic WorkFlowを実現するのが理想。

4. AI駆動開発は全ての開発工程が対象となる 2026/3/13 p10 要件定義単体テスト実装基本設計詳細設計システムテスト統合テスト AI 50% 人 50% AI 60% 人 40% AI 70% 人 30% AI 80% 人 20% AI 70% 人 30% AI 60% 人 40% AI 50% 人 50% ←ポスタスは、まずここの AI駆動開発にトライしました

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p11 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30%

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p12 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30% ←まずはココ

5. 実装フェーズにおけるAI駆動開発 Vibe Coding編 2026/3/13 p13 何を目指すか： AIツールの基礎的な使い方を熟知し、まずはAIにコーディングさせるという基本姿勢を確立すること。必要になる3つのスキル： 1. タスクの特性に応じてモデルを使い分ける力 2. AIツールを使いこなす力 3. AIに依頼するタスクの内容を言語化する力

5. 実装フェーズにおけるAI駆動開発 Vibe Coding編 2026/3/13 p14 ポスタスでもCursorを導入！ Vibe Codingレベルならすぐ達成できるはず...!

5. 実装フェーズにおけるAI駆動開発 Vibe Coding編 2026/3/13 p15 そう簡単にはいかない。 • どう使えばいいか分からない • 使おうとしない、AIコーディングに否定的 • 高額モデルばかり使用する • モデルの使い分けを意識してくれない • そもそもCursorの料金体系を理解していない

5. 実装フェーズにおけるAI駆動開発 Vibe Coding編 2026/3/13 p16 どう乗り越えたか ①Qiitaマニュアル戦略 2年目の新人がいきなりマニュアルを配布しても信ぴょう性に欠ける。 Qiitaで外部にも発信し、いいねの獲得・トレンドにランクインすることでマニュアルに説得力を持たせることに成功！こうすることで、Cursorの料金体系や基本的な使用方法を解説した記事をマニュアルとして展開し、最低限必要なCursorの知識を習得してもらう。

5. 実装フェーズにおけるAI駆動開発 Vibe Coding編 2026/3/13 p17 どう乗り越えたか ②Teamsで継続発信 Cursorのアップデート内容・最新モデルの情報等、マニュアルだけではキャッチアップできない情報をTeamsチャネルで継続的に発信。「このチャネルを見ておけばトレンドは追える」という状態を実現。

5. 実装フェーズにおけるAI駆動開発 Vibe Coding編 2026/3/13 p18 どう乗り越えたか ③管理画面で利用監視一人当たり消費可能なクレジットは月あたり$20。消費ペースが早い、高額モデルばかり消費してるユーザーに対しては MGR経由で注意喚起を徹底し、 $20を超えないように呼びかけ。

5. 実装フェーズにおけるAI駆動開発 Vibe Coding編 2026/3/13 p19 ①Qiitaマニュアル配布によるルール整備 ②Teamsチャネルを通じた最新情報のキャッチアップ ③管理画面での利用モニタリング • いずれも、組織横断的な取り組み。正解が存在せず、トレンドの移り変わりが激しいAI駆動開発では、チームの垣根を超えた知見共有の体制を実現できたことが成功要因。 • Vibe Codingレベルは技術的なハードルよりも心理的なハードルが高いため、組織横断的にAIコーディングを進める文化を構築できるかがどうかが成功の鍵となる。なぜVibeCodingのレベルを達成できたか？

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p20 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30%

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p21 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30% 達成！

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p22 Vibe Coding達成！！これで爆速で開発が進めていけるのか... ？

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p23 Vibe Codingでコーディングは早くなっても、結局手戻りが発生してしまう問題が浮上。 • AIが設計思想に反したコーディングをしてしまう • AIが仕様を満たさないコーディングをしてしまう • AIが出力したコードをセルフレビューするコストが高い • PRでコードの意図を説明できないエンジニアも現れる

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p24 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30% ←次はココ達成！

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p25 何を目指すか：タスクごとに前提・ルール・評価基準を先に設計してからAIに渡すことで、「指示 → ズレた出力 → 修正依頼」という往復そのものを減らすこと必要になる3つのスキル： 1. AIが提案した設計や出力したコードを理解する力 2. AIから質の高い出力を得るために必要な情報が何かを判断し、選択する力 3. 構造化プロンプトを作成する力

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p26 改めて「実装」という業務プロセスを考えてみる設計書既存のソースコード実装新規のソースコードインプットプロセスアウトプット

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p27 もっと細かく考えてみる設計書既存のソースコードインプットプロセス仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング新規のソースコードアウトプット

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p28 もっと細かく考えてみる設計書既存のソースコードインプットプロセス仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング新規のソースコードアウトプットこれらの業務プロセスをAI主体で実現する必要がある。果たして本当に、AIはこのプロセスで作業しているのだろうか？このプロセスで作業するよう、我々はAIに指示ができているのだろうか？

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p29 もっと細かく考えてみる設計書既存のソースコードインプットプロセス仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング新規のソースコードアウトプット

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p30 もっと細かく考えてみる設計書既存のソースコードインプットプロセス仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング新規のソースコードアウトプット AIに正しくインプットを与えられているだろうか？という視点で考えてみる

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p31 AIに与えるインプットを最適化する ①設計書 • 設計書をEXCELで管理していた。 • Cursorにコードを書かせる時、設計書の内容をどう渡していたかは人によってバラバラ。（プロンプトにコピペ貼る、ざっくり要件を書くだけ等）従来のインプット方法 • 設計書をMarkdownファイルで一元管理 • Cursorで実装する時は @シンボルで設計書を参照させることでインプット方法を1つに統一 • MarkdownファイルはAIとの親和性も高いため、より正確なコンテキストとして期待できる改善後のインプット方法

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p32 AIに与えるインプットを最適化する ②既存ソースコード従来のインプット方法 • 対象モジュールが明確である場合は、その部分のみを@シンボルで参照させる。 • AIが変更対象のモジュールを探すにあたり、少しでも選択肢を限定させることで、必要なツールコール数を削減させる。 • 限られたトークン数の中で、AIには本質的な作業のみに集中できるようにインプットを限定する！改善後のインプット方法 • 特に指定しない。該当リポジトリをCursorで開くのみ。

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p33 インプット手法を固定化することによる効果設計書既存のソースコードインプットプロセス仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング新規のソースコードアウトプット Markdown ファイルで一元管理対象モジュールを @で確実に指定

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p34 インプット手法を固定化することによる効果設計書既存のソースコード Markdown ファイルで一元管理対象モジュールを @で確実に指定インプットプロセス仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング新規のソースコードアウトプットインプット手法を固定化・最小化することで、出力の質をプロセスのみに依存させられる。与えるインプットの形式が一定でないと、出力に再現性を持たせることができない。

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p35 設計書既存のソースコードインプットプロセス仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング新規のソースコードアウトプット Markdown ファイルで一元管理対象モジュールを @で確実に指定

次はここに焦点を当てる 5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p36 設計書既存のソースコードインプットプロセス仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング新規のソースコードアウトプット Markdown ファイルで一元管理対象モジュールを @で確実に指定

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p37 仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディングなぜ手戻りが発生するのかを考えるここまでのAIの作業結果と、人間が持つ期待値が異なるために、ズレが発生する。だから手戻りが発生するのでは？

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p38 仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング AIに任せる作業を2つに分割してみる従来仮説仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング ①実装計画作成プロセス ②実装プロセス

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p39 • 設計書の要件を実現するため、どこに何の処理を実装するのか、Cursorに提案させる。 • 各メソッドのシグネチャ・新規か既存か・ステップ単位での処理フロー・エラーハンドリングからバリデーションまで、細かい粒度で書くよう指示をする。 • 開発者は提案内容を理解&レビューし、納得いくまで実装計画書を修正する。 ↑実装計画書作成プロンプト ①実装計画作成プロセス

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p40 • 設計書の要件を実現するため、どこに何の処理を実装するのか、Cursorに提案させる。 • 各メソッドのシグネチャ・新規か既存か・ステップ単位での処理フロー・エラーハンドリングからバリデーションまで、細かい粒度で書くよう指示をする。 • 開発者は提案内容を理解&レビューし、納得いくまで実装計画書を修正する。 ↑使用プロンプト ①実装計画作成プロセス作成する実装計画書のイメージ

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p41 ②実装プロセス • Cursorに、実装計画書通りに実装するようプロンプトで指示を与える • Cursorが実装完了後、開発者は「実装計画書通りに実装されているか」のみに焦点を当ててセルフレビューを実施する。 ↑実装指示プロンプト

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p42 設計書既存のソースコードインプットプロセス仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング新規のソースコードアウトプットプロセスを2つに分割することよる効果 Markdown ファイルで一元管理対象モジュールを @で確実に指定

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p43 設計書既存のソースコードインプットプロセス新規のソースコードアウトプットプロセスを2つに分割することよる効果仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング ①実装計画書の作成 ②実装 Markdown ファイルで一元管理対象モジュールを @で確実に指定

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p44 設計書既存のソースコードインプットプロセス新規のソースコードアウトプットプロセスを2つに分割することよる効果仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング ①実装計画書の作成 ②実装 Markdown ファイルで一元管理対象モジュールを @で確実に指定実装計画書という中間成果物を挟むことで、「人間が本来求めている実装内容」をAIにコンテキストとして付与し、人間の意図と異なるコードの生成を防ぐ。人間は実装計画通りに実装されているかのみに焦点を当ててレビューすればいいため、AI出力に対するレビューコストも削減できる。利点①AIの作業を制御できる利点②理解負債を解消できる

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p45 設計書既存のソースコードインプットプロセス新規のソースコードアウトプット Context Engineeringを振り返る仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング ①実装計画書の作成 ②実装 Markdown ファイルで一元管理対象モジュールを @で確実に指定

5. 実装フェーズにおけるAI駆動開発 Context Engineering編 2026/3/13 p46 設計書既存のソースコードインプットプロセス新規のソースコードアウトプット仕様理解変更対象のモジュール特定責務分割処理ステップに分解コーディング ①実装計画書の作成 ②実装 Markdown ファイルで一元管理対象モジュールを @で確実に指定「実装」という業務プロセスをAIに着実に実行させることで、はじめて期待するアウトプットを得ることが可能となる Context Engineeringを振り返る

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p47 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30% 達成！

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p48 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30% 達成！達成！

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p49 Context Engineering達成！！でも、まだ手を動かす時間残ってますよね...？

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p50 まだ手間になっているポイント • 毎回固定のプロンプトを入力しなければならない • 実装計画書→実装という全体のフローをAIに伝えなければならない。AIがフローを忘れてしまう可能性もある。 • 実装計画書や実装内容に不備がある場合、「修正して」というプロンプトをわざわざ入力しなければならない。 • 人間は、常に実装計画作成・実装のプロセスを把握しておかなければならない。

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p51 Context Engineeringを振り返る ①実装計画書作成プロセス ②実装プロセス ↑実装計画書作成プロンプト ↑実装指示プロンプト

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p52 Context Engineeringを振り返る ①実装計画書作成プロセス ②実装プロセス ↑実装計画書作成プロンプト ↑実装指示プロンプトこのプロセスをワークフロー化したい

5. 実装フェーズにおけるAI駆動開発 Agentic Workflow編 2026/3/13 p53 Context Engineeringのプロセスをワークフロー化する 1. 実装計画書作成プロセス・実装プロセスを実施した Cursorのチャットで、ワークフローファイルを Markdownで作成するように指示 2. 内容に問題がなさそうであれば、 /.cursor/commandsフォルダにワークフローファイル mdを配置このプロセスのみでワークフローの大枠は作成できる。それほど難易度は高くない。 ↑ワークフローファイル作成プロンプト

5. 実装フェーズにおけるAI駆動開発 Agentic Workflow編 2026/3/13 p54 ①実装計画書作成プロセス ②実装プロセス Context Engineering Agentic Workflow 人間はワークフローファイルとインプットを指定するだけで、従来の実装プロセスを実現することができる。ワークフロー化するとどうなるのか

5. 実装フェーズにおけるAI駆動開発 Agentic Workflow編 2026/3/13 p55 プロンプトを再利用してるだけじゃない。

5. 実装フェーズにおけるAI駆動開発 Agentic Workflow 2026/3/13 p56 ワークフローの本質的価値は、業務プロセスの管理を人間からAIに委譲できる点にある。人間が手を動かす作業を極限まで削減した状態を実現する。 Context Engineeringと何が違うのか？変わらないこと • AIに与えるインプット • AIに作業させるプロセス • AIが出力するアウトプット • 人間によるレビュー項目変わること • Context Engineeringでは人間が常に全体像を把握し、現在地と次工程を意識しながらAIの進行管理し続ける必要があるのに対し、ワークフローでは AIが全体のプロセスを踏まえて作業を進めてくれる。 • AIに対して、今どのプロセスの作業を担当しているのか、位置付けを指示しなくてよくなる。

5. 実装フェーズにおけるAI駆動開発 Agentic Workflow 2026/3/13 p57 業務の進め方・意思決定の基準を抽象化した、AIのためのプロセス定義書。自然言語ベースでMarkdownファイルとして記述するのが一般的。ワークフローファイルとはワークフローに記述すること • インプット内容 • 指定されたインプットをどのように利用すべきか • AIが担当する作業内容と、そのプロセス • どのタイミングで人間に承認を求めるのか

5. 実装フェーズにおけるAI駆動開発 Agentic Workflow 2026/3/13 p58 今回作成するワークフローはこれ設計書既存のソースコードインプットプロセス新規のソースコードアウトプット仕様理解変更対象のモジュール特定責務分割処理ステップに分解 ①実装計画書の作成 ②実装 Markdown ファイルで一元管理対象モジュールを @で確実に指定コーディング

ワークフロー化＝この業務プロセスを抽象化する取り組み 5. 実装フェーズにおけるAI駆動開発 Agentic Workflow 2026/3/13 p59 設計書既存のソースコードインプットプロセス新規のソースコードアウトプット仕様理解変更対象のモジュール特定責務分割処理ステップに分解 ①実装計画書の作成 ②実装 Markdown ファイルで一元管理対象モジュールを @で確実に指定コーディング今回作成するワークフローはこれ

2026/3/13 p60 5. 実装フェーズにおけるAI駆動開発 Agentic Workflow 実際にできた実装ワークフロー.md

5. 実装フェーズにおけるAI駆動開発 Agentic Workflow 2026/3/13 p61 こうしてAgentic Workflowが実現するインプットプロセス新規のソースコードアウトプット ①実装計画書の作成 ②実装抽象化された実装ワークフロー.mdが担当する業務プロセス。どのような実装タスクでも、再現性のある実装をAIが実現する。

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p62 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30% 達成！達成！

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p63 Agentic Workflow Context Engineering Vibe Coding 工数削減率 10% 40% 30% ALL達成！

5. 実装フェーズにおけるAI駆動開発 2026/3/13 p64 Agentic Workflowまでの軌跡を振り返る 1. Vibe Coding 2. Context Engineering 3. Agentic Workflow • 技術的難易度は低い。開発者が「AI主体のコーディング」に適応するフェーズ。 • AIツールのノウハウ、コスト方針、LLMの最新情報等を組織横断的に共有できる仕組みづくりが重要となる。 • 最も難易度が高い。AIに与えるインプット・作業プロセスを最適化するフェーズ。 • そもそもAIにどんな作業をさせたいのか、従来の業務プロセスを正しく理解することが重要となる。 • Context Engineeringで業務プロセスを明確化できていれば、難易度は高くない。 • AIに実施させたい業務プロセスを抽象化し、再現性と汎用性を兼ね備えたワークフローを構築できるかが重要となる。

6. ポスタスの課題と今後 2026/3/13 p65 Agentic Workflowを実現しても残る課題 ①レビューのボトルネック化開発者のPR提出までのスピードが激的に向上した結果、レビュアーのレビュー待ち状態が続いてしまっている。検討している対策： • AI駆動開発前提でレビュアーに割くリソースを増やす • AI駆動開発前提で開発者とレビュアーの責任を再定義する • 実装計画書を複数人で、対面でレビューする

6. ポスタスの課題と今後 2026/3/13 p66 Agentic Workflowを実現しても残る課題 ②開発生産性が向上しているか、定量的に測ることが難しい工数の予実管理の手法・見積もり方法がチームによって異なるため、定量的に生産性を測る基準を作りづらい。要件変更など、外的要因による遅延も発生するため証明しづらい検討している対策： • QCDの観点で総合的に生産性向上を証明する • 品質はテスト密度、バグ密度を指標に使用する • コストは、修正ステップあたりの実装工数を指標に使用する • デリバリーは、同程度の改修量だった時にリリースまでの期間を指標に使用する ※ただし案件単位で開発工程ごとの予実管理ができている必要あり

6. ポスタスの課題と今後 2026/3/13 p67 要件定義単体テスト実装基本設計詳細設計システムテスト統合テスト AI 50% 人 50% AI 60% 人 40% AI 70% 人 30% AI 80% 人 20% AI 70% 人 30% AI 60% 人 40% AI 50% 人 50% 達成！ Agentic Workflowへの取り組みはまだまだ続く

6. ポスタスの課題と今後 2026/3/13 p68 要件定義単体テスト実装基本設計詳細設計システムテスト統合テスト AI 50% 人 50% AI 60% 人 40% AI 70% 人 30% AI 80% 人 20% AI 70% 人 30% AI 60% 人 40% AI 50% 人 50% 達成！ Playwrightを使用してテスト打鍵＆証跡保存の自動化ができないか検証中 Excel要件定義書から、 Copilotで設計書の叩き台を作成→Cursorで設計書を仕上げる的なことができないか検証中 Agentic Workflowへの取り組みはまだまだ続く

7. 結論 2026/3/13 p69 Agentic Workflow実現のために人間に必要なことは何だろうか？

7. 結論 2026/3/13 p70 それは、業務プロセスの理解

7. 結論 2026/3/13 p71 AIは「手段」で溢れている • Skills、MCP、SubAgent、 Agent.md、 rulesなど、 AIエージェントを扱う上での概念は増えるばかり • Cursor、Claude Code、Github Copilot、Codex、Devin、 Antigravity等、AIツールも増えるばかり • モデルプロバイダーは常に新しいモデルを提供し続ける

7. 結論 2026/3/13 p72 よくある「手段」に溺れる例「Cursorではrulesってのを定義できて、常に守って欲しいルールをコンテキストとして自動的に付与させられるらしいぞ！！」「rulesでは技術スタックやコーディング規約、採用してるアーキテクチャとかを書くのが一般的なんやって！これがContext Engineeringってやつか！！！」「rules使ったら確かに書いてあるルール守った上でコーディングしてくれる！！」 • そのrulesを作成した根拠は、これまでのCursorの出力傾向を踏まえたものであるか？ • rulesを用意せずとも、最近のLLM性能であれば、既存を準拠したコーディングは全然できるのでは？持つべき視点

7. 結論 2026/3/13 p73 目的思考で、業務プロセスの理解に努めることが先決だから各開発工程の業務プロセスの理解が最重要となる。その業務プロセスを実現するための手段として、AIツールを理解・利用してかなければならない。 AI駆動開発の目的開発工程においてAIを利用することにより、従来のクオリティを担保した上で開発スピードを向上させること。 =最終的なアウトプットは変わらない。 →変わるのは作業主体がAIになるということのみ。 →そのために、従来の開発プロセスの中で「何をAIに任せるか」を明確にする必要がある。

7. 結論 2026/3/13 p74 ご清聴ありがとうございました。

AI駆動開発がもたらすパラダイムシフト

AI駆動開発がもたらすパラダイムシフト

Other Decks in Programming

Featured

Transcript