Transcript
00:00:00ソフトウェア開発が変化したということは、何度も耳にしているかと思います。
00:00:03しかし、新しいツールを採用しただけでは、表面的な対応にすぎません。
00:00:06なぜなら、今日構築されているシステムは、従来のソフトウェアとは異なる挙動を示すからです。
00:00:10そのため、企業が基盤としてきたフレームワークも移行せねばなりませんでした。
00:00:14古いプロセスのまま構築を続ければ、解決できない問題に直面することになるからです。
00:00:18この変化する状況に対応するために、
00:00:21開発者コミュニティでは、AIエージェントを前提とした新しいフレームワークが登場しました。
00:00:25この動画の最後まで見れば、この新しいライフサイクル・フレームワークの概要と、
00:00:29それを導入すべき理由が分かります。
00:00:31長年、ソフトウェア開発はSDLCを用いて行われてきました。
00:00:35ソフトウェア開発ライフサイクルは、何十年も使われてきた構造化されたプロセスであり、
00:00:39設計、開発、テスト、デプロイ、保守、継続的なサポートなど、複数のステップで構成されています。
00:00:45その根底にあるのは、ビジネス目標やユーザー要件を念頭に置いて開発すべきという考え方であり、
00:00:51各フェーズのアウトプットを次のフェーズのインプットにするというものです。
00:00:54しかし、これが機能したのは、AIがテクノロジー分野に参入するまでのことでした。
00:00:57AIが注目を集め始めて以来、最初に代替され始めたのがコーディングでした。
00:01:02AI以前の開発は、コードを何度も書くシステムであり、
00:01:06問題を解決するシステムを構築するために、他からスニペットやロジックをマージする反復的なプロセスであることが多々ありました。
00:01:12そしてモデルが進化し、Claude CodeやCursorのようなツールが業界を席巻するようになると、
00:01:18SDLCは単体では機能しなくなりました。
00:01:20それ自体を維持することはできず、適切な価値を提供するためには変化が必要です。
00:01:24だからこそ、エージェント開発ライフサイクル（ADLC）が開発されたのです。
00:01:28これは、SDLCと現在のテクノロジー分野とのギャップを埋めるものです。
00:01:32ADLCが必要とされたのは、SDLCが使用されていたシステムでは、
00:01:36計画時点でシステムの挙動が分かっており、それを検証する方法が存在していたからです。
00:01:41簡単に言えば、SDLCはソフトウェアを静的なものとして扱うのに対し、ADLCは生きたシステムとして扱います。
00:01:47AIエージェントは予測不可能であり、推論して置かれた環境にタスクを適応させることで
00:01:53実際に進化していくため、従来のソフトウェアと同じ指標で評価することが困難になります。
00:01:59ADLCが開発された最大の理由は、本番環境におけるAIエージェントの非決定性にあります。
00:02:05AIエージェントでは、絶え間ない学習と継続的な開発が行われるため、
00:02:09エージェントのアウトプットがどのようになるかを事前に確定することはできません。
00:02:12AIを扱う場合、下す決定はプロンプト、コンテキスト、モデル、
00:02:16そして接続されているすべての外部ツールに依存します。
00:02:18モデル単体では依然として予測不可能であるため、プロンプトが何を返すかを100%の精度で特定することはできません。
00:02:25そのため、必然的にSDLCとは異なる成功指標を持つことになります。
00:02:29ADLCには7つのフェーズがあり、各フェーズは何らかの形で正確にSDLCのフェーズに対応しています。
00:02:36エージェントシステムを扱っているかどうかにかかわらず、最初のステップは常に「計画」です。
00:02:41変化するのは、その行い方です。
00:02:43エージェントの場合、非エージェントシステムと同じようには計画できません。
00:02:46従来のシステムとは異なり、ロジックのフローが同じようには適用されないからです。
00:02:51そのため、ADLCの最初のフェーズである「準備と仮説」では、
00:02:54システム設計やモデルを決定する前に、問題に対する確固たる理解を構築することを目指します。
00:02:59エージェントに関しては、ユーザーがシステムとどのように対話するのかを理解し、
00:03:04すべての関係者と連携して、ワークフローのどこが破綻しているのか、
00:03:07また、繰り返される手作業がどのようなものかを突き止める必要があります。これこそがエージェントが実際に解決する対象だからです。
00:03:12次に、既存のワークフローやポリシーを確認して、現在どのように処理されているかを把握し、
00:03:16それが明確になったら、エージェントがワークフローのどこを支援または自動化するかについて、テスト可能な仮説を立てます。
00:03:22このフェーズを完全にスキップしてしまうと、誤った業務を自動化することになり、
00:03:26問題を解決するどころか、状況を悪化させる可能性があります。
00:03:28ここでのSDLCとの違いは「挙動」です。
00:03:31SDLCでは、同じ入力が常に同じ出力を返すため、挙動を予測することができました。
00:03:37しかし、ADLCはモデルが関与するため確率論的であり、
00:03:40同じ入力がまったく同じ出力につながるとは限りません。
00:03:43この知識を踏まえ、最初に行うべきステップはプランニングモードをオンにし、
00:03:47使用しているエージェントに、実装ではなく、開発対象のエージェントの「挙動」を計画させることです。
00:03:52コードについては考えず、ワークフロー全体をマッピングするようプロンプトを出します。
00:03:56エージェントがユーザーとどのように対話するか、何が問題になり得るか、どのようなオーバーヘッドが生じるか、
00:04:00およびシステムに関するその他のすべての前提条件です。
00:04:03そうすることで、エージェントの構築プロセスは、核心となる前提条件から始めることができ、
00:04:06いきなりアーキテクチャの計画に飛び込むよりも優れた指針となります。
00:04:10初期の計画が終わると、その直後に別のレイヤーがあり、
00:04:13そこでスコープと問題を適切に特定します。
00:04:16これは実際に、SDLCの「分析フェーズ」や「実現可能性調査」に対応しており、
00:04:20かつてビジネス要件を分析し、実装が実現可能かどうかを判断していたステップです。
00:04:25したがって、ADLCのこのフェーズは、重要なプロセスとそれを解決する上でのAIの役割を特定し、
00:04:31制約や技術的な境界線をマークし、
00:04:33時間、コスト、レイテンシ、実現可能性といった明確なビジネス・技術的KPIを事前に定義することに対応します。
00:04:39また、この時点でトレードオフも定義し、どの要素が許容可能で、どれが許容できないかを把握します。
00:04:44しかし、このフェーズで最も重要な部分は、「人間とエージェントの責任モデル」を適切にマッピングすることです。
00:04:49これによって説明責任の構造が生まれるからです。
00:04:52エージェントにすべての決定を委ねることはできないため、依然として人間がレビューを行う必要があります。
00:04:56このフェーズの終わりには、ワークフローのステップが主要なKPIとともに明示的に定義され、
00:05:02人間とエージェントの責任モデルが明確に提示されます。
00:05:05これが重要なのは、障害が発生した場合に、モデルだけに完全に責任を押し付けることはできないからです。
00:05:09最終的な説明責任は、人間に残る必要があります。
00:05:12この人間の責任に関する計画は、以前はAIが関与していなかったため必要ありませんでした。
00:05:17これはエージェントの自律性の境界を定義するものであり、このステップをスキップすると、
00:05:21本番環境におけるコンプライアンスや説明責任を危険にさらすことになります。
00:05:24これをエージェントで行うには、再びプランニングモードを使用し、ワークフロー、レイテンシ、システムの問題、
00:05:30アーキテクチャに含めるべきすべての機能、および障害がどのようなものになり得るかを計画するようプロンプトを出します。
00:05:34これらが明確に示されれば、エージェントは構築中に反復すべき適切なスコープを理解できます。
00:05:39スコープとハイレベルな機能が定義されたら、次は「設計フェーズ」に進みます。
00:05:43この段階では、エージェント自体のシステムアーキテクチャを定義します。
00:05:47ここでは、エージェントが「ReAct」や「Plan-and-Act」、マルチエージェント構成など、アプローチの中からどのパターンに従うかを決定します。
00:05:54次に、ある地点から別の地点へのデータフローを計画しますが、これは複数のエージェントが関与する場合、より重要になります。
00:06:00エージェントに正しいデータが渡されなければ、支援するどころか問題を引き起こすことになります。
00:06:05また、トークンエコノミクス、コンテキスト編集機能、コンパクションなどのコスト構造を計画し、
00:06:10このエージェントを本番環境にデプロイする際のコストがどうなるか、
00:06:14また複数のユーザーを処理し始めたときに何が起こるかを理解します。
00:06:17ここが、使用するモデル、採用するオーケストレーション・フレームワーク、
00:06:23データベース、および関与するその他のすべてのテクノロジーを実際に選択する場所であり、コードが書かれる前に
00:06:28成功がどのようなものかを定義することで、TDD（テスト駆動開発）でエージェントを構築できるようになります。
00:06:32システムが稼働する前に、レイテンシ、精度、ハルシネーションなどの問題におけるトレードオフをすでに考慮していることになります。
00:06:38このフェーズでも、エージェントのプランニングモードが必要です。
00:06:41エージェント・アーキテクチャ、データフロー、コストモデル、および全体的な技術構造を網羅する
00:06:46包括的な設計を行うようプロンプトを出すことで、具体的な計画を持って次のステップに進むことができます。
00:06:51初期の計画が終わったら、次のステップは「シミュレーションと価値の実証」です。
00:06:55ここでは、現実世界のデータを使用して、前の段階で行った前提条件をテストします。
00:06:59プロトタイプを作成することで、このエージェントの構築をさらに進める価値があるかどうかを判断できます。
00:07:04基本的には、この段階では失敗のコストがはるかに低いため、そもそもエージェントを開発すべきかどうかをここで決定します。
00:07:10したがって、ここでの主な活動には、挙動テストのためのデータセットまたは「グラウンドトゥルース（正解データ）」の準備、
00:07:15以前に記録したリスクの高い前提条件をテストするためのプロトタイプの構築、
00:07:19およびデータ品質、ハルシネーション率、精度、応答品質、ベンチマークの検証が含まれます。
00:07:25また、初期の仮説を再検討し、投資対効果（ROI）が得られるかどうかを判断します。
00:07:30成果物は、適切に測定されたパフォーマンスとコストの基準値であり、
00:07:33前述のグラウンドトゥルース文書と併せて、回帰テストやモデルの微調整のためのテスト資産として機能します。
00:07:40このフェーズは検証ゲートとして機能します。
00:07:42ここでの結果が次の段階に進む基準を満たしていれば、エージェントの開発を継続できます。
00:07:46満たしていなければ構築は失敗ということになりますが、それを早期に発見できる方がはるかに良いことです。
00:07:50これが本番環境に持ち込まれてしまった場合、被害ははるかに深刻になるからです。
00:07:54これを行うには、AIエージェントにプロンプトを出して最初のプロトタイプを作成させ、先ほど行ったすべての計画に対してテストできるようにします。
00:08:00しかし、先に進む前に、スポンサーであるSofterからのお知らせです。
00:08:04バイブコーディング（感覚的なコーディング）ツールはUIの生成には優れていますが、本格的な認証、
00:08:08ユーザー役割、権限、あるいは実際に拡張可能なデータベースが必要になった瞬間に、すべてが破綻し、コードを書く作業に逆戻りしてしまいます。
00:08:14Softerは、それらすべてを1つのプロンプトで処理するAIアプリビルダーです。
00:08:18必要なものを普通の英語（自然言語）で説明するだけで、AI共同ビルダーがフルスタック、データベース、ページ、ナビゲーション、ログイン、および役割ベースの権限をすべて一度に生成します。
00:08:28これらはプロトタイプのページではなく、実際に機能するものです。
00:08:30アプリをプレビューし、各ユーザー役割に何が表示されるかを確認できます。公開ボタンを押せば、ホスティング、ユーザーグループ、エンタープライズグレードのセキュリティ、アクセス制御が組み込まれた状態でアプリがライブになります。
00:08:40また、維持管理のために開発者を必要としません。
00:08:42すべてが視覚的（ビジュアル）であるため、自分でワークフローを更新し、ユーザーを管理し、機能を追加することができます。
00:08:47ソフトウェアの本当のコストは構築することではなく、維持することであり、それこそがSofterが解決する課題です。
00:08:52説明欄のリンクをクリックして無料のAIクレジットを獲得し、今すぐ始めましょう。
00:08:57これで計画フェーズが終了し、多くの人がいきなり飛びつきがちな部分、すなわち「実装」へと移ります。
00:09:03これまでのステップは非常に重要です。これらを適切に行っていれば、フェーズをスキップしたことで大半の人が直面する問題にぶつかることはありません。
00:09:11つまり、この段階で実際にエージェントを開発し、コアロジックを構築し、開発ワークフローをオーケストレーションします。
00:09:16そしてここに、SDLCとADLCの最も明確な分かれ目の1つが見られます。
00:09:20SDLCにおいて、ロジックはコード、設定、およびサードパーティの依存関係の中に存在します。
00:09:25一方、ADLCでは、そのロジックはコード、プロンプト、モデル、ツール、および外部サービスにまたがって分散しています。
00:09:30そのため、もはやソフトウェアだけを管理しているのではなく、これらすべてのレイヤーを統合して管理しており、そのいずれかがシステムの挙動を変える可能性があります。
00:09:38開発すべきマルチエージェントシステムがある場合、ワークフローをオーケストレーションする1つの方法は、Claude Codeの新しいエージェント・ビューです。
00:09:44エージェント・ビューを使用すると、通常のClaudeの使用よりもはるかに適切にタスクを委譲できます。
00:09:49異なるClaude Codeセッションを個別に管理する代わりに、単一のオーケストレーションレイヤーを管理し、エージェントマネージャーにプロンプトを与えて、そこを介してすべてのエージェントを調整するからです。
00:09:57この時点で、MCP（Model Context Protocol）やAPIなどのツールを統合します。
00:10:01例えば、パーソナルアシスタントを構築する場合、GoogleカレンダーMCP、Gmail MCP、そしておそらくNotion MCPのようなものが必要になることが分かります。
00:10:09そして、ここで最も重要なのは「コンテキスト管理」です。
00:10:11なぜなら本番環境向けにエージェントを構築する場合、これが最も重要な側面の1つになるからです。
00:10:16GeminiやOpusの100万トークンウィンドウのように、現在利用可能な最大のコンテキストウィンドウであっても、慎重な取り扱いが必要です。
00:10:24エージェントが正しい記憶を保持し、「コンテキストの腐敗」を回避できるようにしなければなりません。
00:10:28無関係な情報が多すぎると、注意（アテンション）がいたるところに分散してしまい、アウトプットが悪化するからです。
00:10:34また、この段階では開発者側からのテストも必要であり、変更を加えるたびにエージェントの設定を要件に対して手動で検証し、挙動の一貫性を確保します。
00:10:44エージェントシステムにおいて、開発と検証は切り離されたものではありません。
00:10:48わずかな変更であってもワークフロー全体に大きな影響を与える可能性があるため、絶え間ないテストなしに前進することはできません。
00:10:54そのため、後から別のテストステップだけに頼るのではなく、エージェントを構築しながら並行して、開発者レベルでの検証を行う必要があります。
00:11:01システムの構築が完了すると、次のフェーズは「テスト」になります。
00:11:05前述のように、構築プロセス中もテストを継続する必要がありますが、システムが構築された後は、個々のコンポーネントとしてではなく、本番環境に近い条件下でテストを行います。
00:11:14これが「統合テスト」を実施する段階です。
00:11:16また、「ユーザー受け入れテスト（UAT）」も実施し、システムの実際のユーザーからフィードバックを収集してシステムに反映させます。
00:11:24バイアス、コンプライアンス、パフォーマンス、およびその他のリスク関連の側面など、複数の要素にわたってテストを行い、稼働前にリリースが安全であることを確認します。
00:11:32そして、ここでも成功の指標が完全にシフトします。
00:11:35SDLCでは、単に合格（パス）か不合格（フェイル）かで決まるテストを用いて、機能的な正確性を測定していました。
00:11:40ADLCでは、精度分布、ハルシネーション率、成果あたりのコストを測定します。これらはどれも、単一の合格や不合格にすっきりと収まるものではないからです。
00:11:48テストのパラダイムそのものも、それに伴って移行します。
00:11:50SDLCでは、あらかじめ定義されたテストによって既知のコードパスを検証していました。
00:11:54ADLCでは、エージェントが同じ経路を二度と同じように実行しないため、推論、安全性、およびツールの使用の「継続的な評価」になります。
00:12:02RAGASやDEEPEVAL（DPVAL）のような複数の評価フレームワークが存在しますが、正確性を検証する主な要素は、先に定義した指標に対してデータがどのように機能するかです。
00:12:12また、エージェントシステムをテストする方法には、機能テスト、非機能テスト、構造テスト、負荷テストなど、いくつかのアプローチがあります。
00:12:18これらそれぞれを徹底的に実施する必要があり、本番環境に到達する前にエッジケースを適切に特定して修正するために、エージェントシステム自体を利用することがよくあります。
00:12:27また、コンテンツを楽しんでいただけているなら、高評価ボタン（hype button）を押すことを検討してください。より多くのコンテンツを作成し、多くの人に届ける励みになります。
00:12:34システムが整ったら、それをデプロイして現実世界で利用できるようにする番です。
00:12:39直接デプロイして終わりというわけではありません。エージェントシステムでは、さらに多くのことが関与してくるからです。
00:12:44通常のシステムにおけるデプロイとは、通常、本番環境にプッシュしてシステムの健全性を監視することを意味します。
00:12:49エージェントシステムでは状況が完全に異なり、ここでデプロイそのものの意味が変化します。
00:12:54SDLCにおいて、デプロイは開発の終了であり、安定した運用フェーズの始まり、つまりソフトウェアが安定期に入る時点を指していました。
00:13:02ADLCにおいて、デプロイは「能動的な監視と制御」の始まりであり、移行した後も動き続けるモデルの更新、コンテキストのドリフト、環境の変化によって形作られます。
00:13:11そのため、開発自体は完了しているかもしれませんが、この段階はさらに重要になります。挙動やシステムの指標を積極的に監視しなければならないからです。
00:13:19また、品質、安全性、パフォーマンスの問題を常に監視するアラートルールも必要であり、これによって、大規模な本番環境のエラーに発展する前に早期にキャッチできます。
00:13:28デプロイとは、本質的には、実際のユーザーがシステムと対話する中での「継続的な観察を伴う、制御されたアクティベーション」です。
00:13:34システムの健全性だけに焦点を当てるのではなく、挙動のパフォーマンスに焦点を当てることで、すべてのユーザーに届く前に問題を早期に特定できます。
00:13:41実際には、まず限定されたユーザーグループにシステムをリリースし、実際の条件下で使用してもらいます。
00:13:46その後、エージェントシステムが時間の経過とともにどのように応答するかを観察してから、段階的に全員に展開（ロールアウト）していきます。
00:13:52実装がすべてのプロセスを経た後は、保守、継続的な学習、および成長の継続的なサイクルへと移行します。
00:13:58これは、エージェントの正確性を保ち、現実世界のニーズに合わせ続けるための重要な段階です。
00:14:03従来のシステムでは、フィードバックループは比較的シンプルでした。
00:14:06ユーザーがバグを報告し、開発者がそれを反復処理して修正します。
00:14:10エージェントシステムでは状況がかなり異なります。いかなる時点でも停止することのない、継続的な改善プロセスに基づいているからです。
00:14:16このサイクルはモデルを洗練し続け、すべてのネガティブなシグナルがフィードバックとして戻されるため、時間の経過とともに挙動を改善することができます。
00:14:22これは通常、応答後にユーザーがどのように感じたかを捉えるために、親指アップや親指ダウン（いいね・よくないね）のようなUIシグナルを通じて行われます。
00:14:29多くの本番システムでは、ChatGPTで見られるような複数の出力からの選択や応答のランキング、あるいはClaudeのフィードバックシステムなど、すでに同様のメカニズムが使用されています。
00:14:39これらのシグナルがエージェントシステムにフィードバックされ、学習してより良いパフォーマンスに向けて反復できるようになります。
00:14:44また、システムが最新の状態を保ち、古い情報による問題が発生しないようにするために、データソースや埋め込み（エンベディング）の定期的な更新も行われます。
00:14:52プロンプトインジェクションのようなリスクを含む、あらゆるタイプのプロンプトに対して安全性やガードレールが有効であり続けるよう、アライメントを常に監視する必要があります。
00:15:00ここでの主要な変数には、継続的なコスト管理、品質追跡、製品改善のバックログ、モデルのアップグレードなどがあり、システムを長期にわたって安定させ、安全に、運用可能な状態に維持するために、これらすべてを継続的に保守する必要があります。
00:15:11これでこの動画は終わりです。
00:15:13チャンネルをサポートし、このような動画を作り続けるのを手助けしたい場合は、下の「Super Thanks」ボタンから支援することができます。
00:15:20いつもご視聴ありがとうございます。それでは、また次の動画でお会いしましょう。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video