WEBVTT 00:00:00.000 --> 00:00:10.260 マイクロソフト365コパイロット ai アジュールそして働き方の未来を築く人々が集う10日間 準備はいいですかこの1月 m 365コンが帰ってきます 00:00:10.260 --> 00:00:18.140 さらに規模を拡大してお届けしますライブセッションや実践的なデモ 世界中の mvp や業界エキスパートによる知見をぜひ体験してください 00:00:18.140 --> 00:00:24.480 ありきたりなスライドは一切ありません無意味な専門用語の羅列もありません コパイロットスタジオ ai エージェント 00:00:24.480 --> 00:00:35.160 ファブリックセキュリティガバナンス自動化といった現実の課題に取り組みます it プロフェッショナル開発者ビジネスリーダーの皆様それぞれのニーズに合わせたセッションを用意しています 00:00:35.160 --> 00:00:44.860 充実した10日間で多様な技術を探求し世界中のコミュニティとつながりましょう ライブ配信を見て組織ですぐに役立つ実践的な知見を持ち帰ってください 00:00:44.860 --> 00:00:56.200 2027年1月10日間一つのマイクロソフトコミュニティ登録受付を開始しました メートル365コンドットネットにアクセスして今すぐ参加枠を確保しましょう 00:00:56.200 --> 00:01:04.760 サイトはメートル365コンドットネットです メートル365コンドットネットから今すぐ登録を1月のライブでお会いしましょう 00:01:04.760 --> 00:01:10.560 ソリューションを開いた瞬間複雑に絡み合うファイルや参照 そして待ち受けるバグの山に圧倒された経験はありませんか 00:01:10.560 --> 00:01:15.540 それはあなただけではありません 多くの開発者はあちらをパッチしこちらをデバッグするという受け身の作業に追われています 00:01:15.540 --> 00:01:20.280 GitHubコパイロットのエージェントモードはより広い文脈を理解し ファイル間をまたぐ変更を調整することを目指しています 00:01:20.280 --> 00:01:25.200 この動画では実際のドットネットおよびアジュールプロジェクトでそのワークフローがどう機能するかを実演します 00:01:25.200 --> 00:01:33.260 ライブ環境のソリューションを通じエージェント利用前後の変化をお見せします 最小限の手間で複数ファイルのコードを生成しファイル間のエラーを迅速に解消する様子や 00:01:33.260 --> 00:01:41.380 自然言語の使用から機能をスケルトン生成する方法をご覧いただきます その前に私たちが日常的に陥っているデバッグループに隠されたコストについて考えてみましょう 00:01:41.380 --> 00:01:46.580 パッチワーク的なデバッグに隠されたコスト 一見シンプルに見えるエラーを修正しようと取り組み始めます 00:01:46.580 --> 00:01:53.620 アプリケーションはビルドできずコンソールはメインプロジェクトファイルの行を指摘します メソッドを微調整して再コンパイルし解決したと思った矢先 00:01:53.620 --> 00:01:59.320 わずかに形を変えた同じメッセージが再表示されます さらに30分が経過しようやく真の問題に気づきます 00:02:03.260 --> 00:02:11.020 を修正して再デプロイする頃には午後の大半がパッチワーク作業で消えてしまいます 予定していた機能開発は明日に持ち越しですこのパターンは非常によくあるため 00:02:11.020 --> 00:02:15.520 もはや当たり前のように感じられます バグを一つ潰すたびに達成感があるため表面上は前進しているように見えます 00:02:15.520 --> 00:02:21.280 しかし実際には同じ場所をぐるぐると回っているだけです コードを書くコンパイルするエラーが出る修正する繰り返すこのループです 00:02:21.280 --> 00:02:26.420 因果関係を追いかけるだけで何時間も失われ その結果得られるのは有意義な進歩ではなくバータリ的な対応にすぎません 00:02:26.420 --> 00:02:31.020 このループにはまって午後を丸ごと無駄にしてしまった経験がある方はどれくらいいらっしゃいますか 一言コメントをどうぞ 00:02:31.020 --> 00:02:37.560 上位の変身には目を通します このサイクルが疲弊を招くのは周囲のツールは進化し続けているのにパターンが変わらないからです 00:02:37.560 --> 00:02:43.720 エディタは新機能を追加しフレームワークは進化し統合は深まっていますがデバッグは依然として受動的なアプローチを強いています 00:02:43.720 --> 00:02:51.180 それは燃え広がる火をバケツ一杯の水で食い止めようとするようなものです 発生した火種はその場しのぎで対応されますがそれを引き起こした根本的な条件は残ったままであり 00:02:51.180 --> 00:02:59.960 次の火災をほぼ確実に招きますそしてタブを切り替えるたびに隠れたコストが積み上がっていきます サービスクラスから設定ファイルへそして依存関係グラフへと飛び回ります 00:02:59.960 --> 00:03:09.700 切り替えるたびに思考の糸は途切れその都度メンタルをリセットしなければなりません 単にウィンドウの切り替えに数秒かかるだけでなく何度もコンテキストを再構築する精神的負担がのしかかるのです 00:03:09.700 --> 00:03:16.840 1日を通すとそうした小さなリセットが積み重なって大きな負担となります ここの開発者にとってその疲労はフラストレーションと時間の浪費として現れます 00:03:16.840 --> 00:03:26.780 エンタープライズプロジェクトに取り組むチームにとってはその影響はさらに増幅されます デバッグのループはスプリントの目標を起動から外し機能のリリースを遅らせ解消よりも蓄積が早いバックログを生み出します 00:03:26.780 --> 00:03:35.680 技術的負債の増大も火消しに費やされる時間の副作用にすぎません 多くのチームが開発時間の大部分を受動的なデバッグに吸い取られていると報告しています 00:03:35.680 --> 00:03:41.480 これはエンジニアリングの醍醐味ではありません 同じ依存関係の不一致を5度も追うような計画を立てる人はいません 00:03:41.480 --> 00:03:50.480 それにも関わらず週ごとにリソースの多くがそこに割かれています エラー修正が進捗と定義されてしまうと新機能の開発は二の次となり裏側でアーキテクチャは静かに 00:03:50.480 --> 00:03:55.520 疲弊していきます 受け入れがたい真実ですが継ぎはぎだらけのデバッグは単に作業を遅らせるだけではありません 00:03:55.520 --> 00:04:02.200 設計ではなく反応の文化を助長してしまうのです あなたはシステムを構築しているのではなくただ火を消すことに時間を費やしています 00:04:02.200 --> 00:04:07.520 それは短期的には製品を維持できるかもしれませんがチームのスケールと確信を持ったリリース能力を制限してしまいます 00:04:07.520 --> 00:04:14.780 では火消しというイメージで一度立ち止まってみましょう 火元へ駆けつけ水をかけ次へ進む問題は開発者がそれが下手なことではありません 00:04:14.780 --> 00:04:24.100 彼らは十分に優秀です問題は炎がいつまでも消えないことです 炎は場所を変え新しいファイルやプロジェクト設定で燃え上がり全員を創造モードではなく対応モードに 00:04:24.100 --> 00:04:29.560 縛り付けます そこで疑問が生じますこのサイクルをあなた一人で背負う必要がなかったとしたらどうでしょうか 00:04:29.560 --> 00:04:41.060 もし追跡切り替え修正といった繰り返しの作業を別の方法で管理しあなたは構築だけに集中できるとしたら 火消しの負担は明らかですがまだ触れていない別の圧力の点が存在するからです 00:04:41.060 --> 00:04:48.400 プロジェクトが単一のファイルやモジュールではないとき本当の重圧がかかります 修正すべき箇所が複数のレイヤーにまたがるときこそそれが起こります 00:04:48.400 --> 00:04:57.400 ロジックが異なるプロジェクトサービスライブラリ全体に散らばっているソリューションを 開くところを想像してみてください必要なパーツが同時に3箇所に存在し 00:04:57.400 --> 00:05:03.860 それを頭の中で整理するだけでも一苦労です マルチファイルの混沌と ai によるコンテキスト制御 00:05:03.860 --> 00:05:08.400 プロジェクトが複数のレイヤーにまたがる場合 真の課題はコードを書くことではありません 00:05:08.400 --> 00:05:15.820 すべての稼働パーツを統合し続けることです ここにマルチファイルの混沌と ai 主導のコンテキスト制御との間の緊張関係が最も明確に現れます 00:05:15.820 --> 00:05:22.500 10以上のプロジェクトを含む大規模な.netソリューションを例に挙げましょう 新しい機能は通常複数のレイヤーに同時に影響を与えます 00:05:22.500 --> 00:05:27.560 コントローラーが1箇所サービスが別の場所 そして設定ファイル群がまた別の場所に存在します 00:05:27.560 --> 00:05:35.540 コードを一興書く前に参照をたどり依存関係を確認することに時間を費やします 小さな変更が連鎖的に予期せぬ破壊を引き起こさないことを願いながら 00:05:35.540 --> 00:05:39.920 そのワークフローは例外ではありません エンタープライズアプリケーションでは普通のことです 00:05:39.920 --> 00:05:45.240 特にアジュールサービスや統合が関わってくると顕著になります こうしたシステムの構造はフラットではありません 00:05:45.240 --> 00:05:50.080 インターフェース依存関係の注入マッピング プロジェクト間の参照がすべて役割を果たしています 00:05:50.080 --> 00:05:58.340 アジュールが混ざると関数アプリサービスバスのバインディング リソース設定ストレージ接続などソリューションホルダーの外側にある依存関係も現れます 00:05:58.340 --> 00:06:03.760 IDE内のコードディスク上の設定ファイル そしてクラウドで定義されたサービスの間で調整を行う必要があります 00:06:03.760 --> 00:06:10.240 それらはどれもあなたがクリック数を減らしたいことなど考慮してくれません コンテキストを切り替えるたびに全体像を再構築するためにエネルギーを消費します 00:06:10.240 --> 00:06:16.680 私たちのほとんどはそのコンテキストをワーキングメモリの中でやりくりしようとします 最初はうまくいきますがプロジェクトが成長するにつれてミスが入り込みます 00:06:16.680 --> 00:06:19.980 サービスに新しいメソッドを追加してもDI登録を忘れてしまうのです 00:06:19.980 --> 00:06:25.140 アジュール関数をコーディングしたもののホスト jsonやデプロイテンプレートへのバインディング追加を忘れていたことに後で気づくといった具合です 00:06:25.140 --> 00:06:34.080 実行時まで何も通知されずビルドではなくデバッグに追われることになります コード自体は難しい部分ではありません難しいのはファイル間での調整ですコントローラーからサービス 00:06:34.080 --> 00:06:41.640 モデル設定ファイルへとタブを行き来し結局なぜそのファイルを開いたのか忘れてしまう あの感覚は誰もが知っているはずです 00:06:41.640 --> 00:06:48.580 それは1日に何度も繰り返される小さな中断です それらのやりとりが積み重なり実際の進捗を遅らせる摩擦を生み出します 00:06:48.580 --> 00:06:54.140 結果として配信が遅れます それは書くのが遅いからではなくすべてを同期させることが集中力を奪うからです 00:06:54.140 --> 00:07:01.140 このオーバーヘッドはクラウドファーストのプロジェクトでより増大します アジュールは重要な設定をローカル構成ファイル環境変数 00:07:01.140 --> 00:07:11.020 アームバイセップテンプレート ci cd パイプラインなど複数の場所に分散させます 一見単純な機能リクエストに見えるものでも多くの場合4つの抽象化レイヤーにまたがっています 00:07:11.020 --> 00:07:18.240 この複雑さは避けられませんエコシステムの仕組みそのものに組み込まれているからです そこで大きな転換点となり得るのがエージェントモードです 00:07:18.240 --> 00:07:27.140 すべてを自分で調整するのではなく複数のファイルにまたがる広範なコンテキストを保持できるように設計されています つまりあるレイヤーに変更を求めても他のレイヤーがおざなりになることはありません 00:07:27.140 --> 00:07:34.680 でもでは新しいアジュールファンクションを作成しエージェントがどのようにメソッド本体の生成 バインディング構成の作成ホストの更新を支援するかをお見せします 00:07:34.680 --> 00:07:41.200 ジェイソンの更新や適切なDI登録の提案まで行います 通常これは複数のファイルにまたがる複雑なプロセスです 00:07:41.200 --> 00:07:50.500 エージェントならそれを一つのフローに効率化できます これは皆さんの判断に変わるものではなく繰り返しの事務作業を取り除き設計の本質的な選択に集中できるようにするためのものです 00:07:50.500 --> 00:07:58.020 人間は頭の中やホワイトボードに大まかな概要を書くことができます AIはファイル単位で詳細を追跡し筋道を見失うことがありません 00:07:58.020 --> 00:08:07.180 私たちにとって大きな認知的負荷となる作業もエージェントにとっては基本的なコンテキストにすぎません 実際の違いはタブを行き来する断片的な作業から同期を持った計画的な変更へと移行できる点にあります 00:08:07.180 --> 00:08:14.240 デモ中にエージェントが作成したプルリクエストや差分を表示しどのような編集が行われたかを正確にご確認いただきます その可視性が重要なのです 00:08:14.240 --> 00:08:23.040 皆さんはレビューと承認の全権を維持したまま複数のファイルを更新する面倒な作業を代行させることができます つまり午後の時間を断片的なコードの継ぎ剥ぎに費やす代わりに一度変更を指示し 00:08:23.040 --> 00:08:31.360 生成された更新を確認してより高次元な設計へと移行できるのです その恩恵はクリック数やキー入力の削減だけでなく多数のファイルの関連性をたどるのではなく 00:08:31.360 --> 00:08:37.060 本質的な問題解決に集中できる点にあります この利点が最も明確になるのはシステムが壊れた時です 00:08:37.060 --> 00:08:43.760 コンテキスト処理が強力であってもシステム障害や設定のズレ 参照の不一致は再び発生し得るからですそこで次のテストが始まります 00:08:43.760 --> 00:08:52.780 エラーが表面化した際にそれをどのように追跡し解決するかという点です エラー探しから自律的な修正へ単一のファイルを指し示すエラーメッセージにどれほど頻繁に遭 00:08:52.780 --> 00:08:58.160 するか考えてみてください スタックトレースに従って指定されたメソッドを修正しリビルドを実行します 00:08:58.160 --> 00:09:06.580 それが明白な解決策に思えますがすぐに少し形を変えた同じエラーが再発します そこで初めてスタックトレースが示していたのは症状に過ぎなかったと気づくのです 00:09:06.580 --> 00:09:11.560 真の問題は全く別の場所にありサポートクラスの中や1週間開いてもいなかった設定 ファイルに隠れているかもしれません 00:09:11.560 --> 00:09:16.920 すべての開発者がこのようなミスリードを経験したことがあるはずです 問題だと思える場所が必ずしも修正すべき箇所とは限りません 00:09:16.920 --> 00:09:25.080 これは時間を大きく浪費します 一つ調整してリビルドし待機するすると新たなエラーが発生し別のファイル別の修正またリビルドへと続きます 00:09:25.080 --> 00:09:32.320 動いてタイピングして再コンパイルしているため生産的に見えますが実際には本質的な解決ではなく試行錯誤を繰り返しているだけです 00:09:32.320 --> 00:09:41.160 そのサイクルは時間を奪うだけで表面的な修正はできても本来の機能開発は一向に進みません ここで失われているのは本来得られたはずの成果です 00:09:41.160 --> 00:09:47.400 リビルドと再試行に追われている間ビジネス上の課題解決もユーザーが待望する機能の提供も止まったままになります 00:09:47.400 --> 00:09:56.120 前進する力は設計ではなく当て水量へと消えていきます その瞬間は活動しているように感じますが結局のところシステムを壊さないための対応に追われているにすぎません 00:09:56.120 --> 00:10:05.000 チーム全体で見ればこうした表面的な作業がすべてを停滞させ機能のバックログが溜まり続けてしまいます ここでエージェントワークフローという考え方が重要になります 00:10:05.000 --> 00:10:08.780 スタックトレースが示すたった一向で止まるのではなくその先を見据えるのです 00:10:08.780 --> 00:10:17.900 システム全体の文脈を理解しそのファイルが何をすべきかだけでなく 一貫性を保つためにどの連鎖的な修正が必要かを判断します 00:10:17.900 --> 00:10:28.620 実際には複数のファイルにまたがる編集案が提示されることもあるでしょう 例えばメソッドに変更が必要な場合関連する設定ファイルやデプロイテンプレートの修正も合わせて提案してくれます 00:10:28.620 --> 00:10:33.880 自分で探し回る必要はありません これこそが単なるオートコンプリートから一歩踏み出した進化です 00:10:33.880 --> 00:10:40.600 オートコンプリート破業を保管しますがエージェントはファイル間を調整します エラーが複数の箇所に散らばっているときにこそこの調整能力がいきます 00:10:40.600 --> 00:10:44.940 azureの一般的なシナリオを例に挙げましょう 新しい関数アプリを作成しデプロイしたところ 00:10:44.940 --> 00:10:48.500 バインディングとメソッドのシグネチャが一致せず 旧のトリガーが失敗するというケースです 00:10:48.500 --> 00:10:54.360 通常ならログを掘り下げどのバインディングが間違っているかを特定し 手動で関数ジェイソンを調整し 00:10:54.360 --> 00:11:01.520 インフラテンプレートの不一致まで修正しなければなりません 全てのステップが個別の追跡作業となり修正の度にテストを繰り返すことになります 00:11:01.520 --> 00:11:07.840 エージェントモードを使えばワークフローは一変します コード修正の提案に加え適切な関数ジェイソンバインディングを生成し 00:11:07.840 --> 00:11:13.520 デプロイスクリプトの不一致があればそれも修正してくれます あとは確認して承認するだけ各層をつなぎ合わせるために何時間も 00:11:13.520 --> 00:11:18.760 費やす必要はありませんここで重要なのは信頼です 自分の知らないところで勝手にコードが書き換わるような不安を感じさせてはいけません 00:11:18.760 --> 00:11:22.660 だからこそレビュープロセスが不可欠なのです 今回のデモではその流れを一緒に見ていきましょう 00:11:22.660 --> 00:11:30.560 エージェントが最適化された一連の変更を提案します 差分を開いて生成されたコードを精査しユニットテストを実行しローカルでビルドを検証した上で 00:11:30.560 --> 00:11:37.200 編集内容を適用するかどうかを判断します その検証ループにより単純作業を排除しながらも完全にコントロールを維持できます 00:11:37.200 --> 00:11:42.300 強調しておきたいのはエージェントは開発を加速させますが優れたエンジニアリングの習慣に とって変わるものではないということです 00:11:42.300 --> 00:11:50.620 コードレビューやciは依然として不可欠な関門として扱うべきです ai に調査時間を短縮させる一方で自動チェックと人間によるレビューをセーフティネットとして 00:11:50.620 --> 00:11:55.700 維持してください そのバランスこそが信頼の問題を解決しスピード向上が安定性を損なわないようにします 00:11:55.700 --> 00:12:03.420 そのスピードの差は理論上の話ではありません エラーの追跡と手作業での修正に半日かかるような作業も統合された提案があれば数分に短縮できます 00:12:03.420 --> 00:12:11.500 そして取り戻した時間は本来注力したい作業に当てることができます ユーザーが実感する機能の開発やコードベースを改善するアーキテクチャの設計などです 00:12:11.500 --> 00:12:18.440 実行時のトラブル対応に追われるのではなく自信を持って前もって設計できるようになります つまりデバッグのループに1日を支配される必要はなくなるのです 00:12:18.440 --> 00:12:30.080 エージェントがファイル間を横断する更新を提案することで手探りの検索からレビューと承認を行うリズムへとシフトします エラーを堂々巡りするのではなくデバッグをワークフローにおける構造化されたほぼ自動化されたステップとして扱うようになります 00:12:30.080 --> 00:12:39.520 そのシフトにより知的リソースと時間を確保し単なる欠陥修正ではなく機能構築に集中できるようになります またエラー修正が単なる症状の追跡ではなくなればより大きな可能性への扉が開かれます 00:12:39.520 --> 00:12:50.560 機能全体を同じ構造化された方法で開始する方法についてです 統合された修正を提案するのと同じワークフローが平易な言葉による使用書を受け取りそれを機に機能する構造を構築できるとしたらどうでしょうか 00:12:50.560 --> 00:12:55.960 そこから開発の次のステージが始まります オーバーヘッドのない使用駆動型開発です 00:12:55.960 --> 00:13:02.660 最も興味深い変化の一つはファイルやメソッドのことばかりを考えるのをやめ 平易な言葉で作業を組み立てるようになることです 00:13:02.660 --> 00:13:08.620 そこで登場するのがオーバーヘッドのない使用駆動型開発です 簡単な機能リクエストを書くところを想像してみてください 00:13:08.620 --> 00:13:14.520 月次サマリーを生成し保存し管理ページから利用できるようにするレポート作成ワークフローを追加するといった内容です 00:13:14.520 --> 00:13:24.080 単に断片的な行動を受け取るのではなくアプリ全体にマップされた動作する構造が返ってきます コントローラーのスタブが作成されモデルが生成されサービスが登録され設定が 00:13:24.080 --> 00:13:31.820 紐づけられます 糸を記述してからプロジェクト内に具体的な骨組みが出現するまでの流れこそがこのアプローチを理論だけでなく実践的なものにしています 00:13:31.820 --> 00:13:41.780 従来の設定において使用先行型の開発は重苦しいという評価があります 大企業では通常長大な要件定義書や何ページにも渡る設計書硬直的な図表を意味し全体のペースを遅らせて 00:13:41.780 --> 00:13:47.700 しまいます 規制の厳しい業界や世界中に分散したチームでは意味がありますが日々のコーディングにおいて多くの開発者はそれらを省略しています 00:13:47.700 --> 00:13:57.420 詳細な使用書の作成と維持にはコストがかかりそれに耐えられる忍耐も時間も誰にもありません 機能のリリースに加えて余分な作業が発生し締め切りが迫ると通常そうした予備的な作業は削られて 00:13:57.420 --> 00:14:01.460 しまいます 皮肉なことに開発者は本来もっと対極的に考えることを好むものです 00:14:01.460 --> 00:14:10.660 あらかじめ構造を把握しておくことは安心感につながります 問題なのは意図ではなく維持管理のコストです一度使用書が現実と食い違い始めるとそのメンテナンスは主にとなります 00:14:10.660 --> 00:14:20.200 そのため厳密な計画を掲げている現場でさえ現実の仕事の多くは完全な設計よりもその場しのぎに 流れてしまうのですエージェントワークフローはその代替案となります 00:14:20.200 --> 00:14:26.160 完璧な設計ドキュメントを求める代わりに平易な言葉で書かれた仕様を改良可能な スケルトンに変換する手助けをしてくれます 00:14:26.160 --> 00:14:32.940 umlsや手書きのインターフェースマップは不要です 新しい api エンドポイントを持つレポートモジュールを作成し 00:14:32.940 --> 00:14:40.660 ストレージにリンクしてロールベースアクセスで保護すると伝えるだけで システムが.net ソリューション全体のベースラインを生成します 00:14:40.660 --> 00:14:47.960 デモでは平易な言葉で書かれた仕様を読み上げ エージェントが作成したコントローラーモデルサービス登録のファイルを示し 00:14:47.960 --> 00:14:53.480 手動での調整が必要だった箇所を指摘します そうすればあなた自身で品質を判断できるはずです 00:14:53.480 --> 00:14:58.900 これは2つの開発スタイルの中間点を作り出すものです 一方にはバイブコーディング感覚的なコーディングがあります 00:14:58.900 --> 00:15:03.600 高速で自由ですが長期的なシステムには脆いものです もう一方には使用駆動型設計があります 00:15:03.600 --> 00:15:09.940 信頼性は高いですが非常に時間がかかります エージェントのサポートがあれば自然言語でアイデアを解説するだけでスケルトンが現れ 00:15:09.940 --> 00:15:16.560 構造化された利点を保ちつつバイブコーディングとほぼ同じ速さで反復開発が可能です 先ほどのレポート作成のワークフローを例に挙げましょう 00:15:16.560 --> 00:15:23.380 通常ならモデルを作成しデータサービスを構築しコントローラーを配線しセキュリティを設定し 起動時にすべてを接続しなければなりません 00:15:23.380 --> 00:15:29.920 つまり複数のファイルを行き来しながら一貫性が保たれていることを願うことになります このアプローチならスケルトンが一気に配置されます 00:15:29.920 --> 00:15:36.820 真の効率化はタイピングの量を減らすことよりも新しいサービスを構築したのに登録を 忘れるといったファイル間でのミスを防ぐことにあります 00:15:36.820 --> 00:15:42.400 もちろんスタイルの問題は常にあります ai は提携行動を押し付けたり監修を上書きしたりしないでしょうか 00:15:42.400 --> 00:15:46.380 実際にはエージェントは既存のプロジェクトのパターンを反映して提案することが多いのです 00:15:46.380 --> 00:15:53.820 デモではその両面をご覧に入れます 開発チームのコントローラー構造と完全に一致した箇所と ai の推測が少しずれてしまった箇所があります 00:15:53.820 --> 00:15:58.320 その混在が重要なのです どこを信頼しどこを調整すべきかがわかるようになります 00:15:58.320 --> 00:16:04.280 最終結果は型通りのコードではありません 手作業のスケルトン作成が減るだけで完成したコードは依然としてあなたのプロジェクトそのものです 00:16:04.280 --> 00:16:09.000 スピードを維持しながら将来の拡張に向けて洗練可能な基盤に依存し続けることができます 00:16:09.000 --> 00:16:17.540 使用策定作業は図表作成に根気のあるアーキテクトだけのものではなくなり 秩序を犠牲にすることなく素早く試行錯誤したい全ての開発者にとってのツールとなります 00:16:17.540 --> 00:16:24.860 これが日常のフローの一部になると使用策定は堅苦しい企業向けのプロセスではなく より軽量なショートハンドのように感じられるようになります 00:16:24.860 --> 00:16:29.560 意図を記述すればシステムが基盤を構築し自分は細部の調整に専念できるようになります 00:16:29.560 --> 00:16:35.000 より大きなインパクトは生成されるコードそのものだけでなく毎週積み重なる時間短縮から生まれます 00:16:35.000 --> 00:16:41.600 機能開発に割く時間が増えセットアップの苦労が減ります そこですべての開発者が最も気にかける疑問に直面します 00:16:41.600 --> 00:16:50.520 これらの変化が生産性の面で具体的にどれほどの成果につながるのかという点です 生産性という対価重要なのはここぞという時に数分節約できるかどうかではなく 00:16:50.520 --> 00:16:56.740 そうした小さな変化が週単位でどれほど意味のある時間に積み重なるかということです これこそが生産性という対価です 00:16:56.740 --> 00:17:02.180 コンテキストスイッチ繰り返されるビルドサイクル 手作業での修正など普段は気づかないうちに失われている時間を取り戻すのです 00:17:02.180 --> 00:17:11.900 多くの開発者はそうした小さな損失を仕事の一部として受け入れています 設定値の確認に10分参照ミスによる再実行25分あるいは接続確認のためにファイル感を行き来するなどです 00:17:11.900 --> 00:17:18.400 ここで見れば些細なことに思えます しかしスプリント全体で合算すれば実際にどれだけの価値を提供できるかを左右します 00:17:18.400 --> 00:17:25.160 日常のルーチンに見えるものが実は脳機を遅らせる大きな足枷となっているのです 隠れた主にはコンパイル時間やタイピング速度ではありません 00:17:25.160 --> 00:17:32.680 集中力を削ぐ止めては動かすというリズムにあります ファイルから別のファイルへ移るたびに脳はリセットされますそのリセットには代償が伴います 00:17:32.680 --> 00:17:41.700 反復的な修正をエージェントに任せることでその負担は軽減されます コンテキストを絶えず再構築する代わりにより重要な設計上の問題解決に集中力を使えるようになります 00:17:41.700 --> 00:17:46.900 多くのチームはこれらの微細なコストを追跡していません ジラチケットやギット履歴には現れないからです 00:17:46.900 --> 00:17:53.840 成果につながらない作業は記録されませんがそれでも確実にエネルギーを消耗します コードベースが拡大するにつれこの摩擦は単なる線形以上の増加を見せます 00:17:53.840 --> 00:17:59.680 レイヤーが増えれば記憶しておくべき依存関係も増え先に進む前に構造を整えるだけで時間を 浪費する機会も増えます 00:17:59.680 --> 00:18:05.760 エージェントワークフローはこうした時間浪費の要因に直接働きかけることで計算式を書き換えます 単にメソッドのスタブを早く埋めるだけではありません 00:18:05.760 --> 00:18:14.220 午後を食いつぶすような検索修正再実行のループを減らしてくれるのです エージェントワークフローを利用しているチームからは多くの場合問題解決までの時間が短縮されたと報告されています 00:18:14.220 --> 00:18:23.160 この動画ではインパクトを判断いただけるようビフォーアフターのタスクを一つ実演します 同じアジュール機能を実装するのにかかる時間を手作業の場合とエージェントを使う場合で記録し 00:18:23.160 --> 00:18:29.020 生産性の向上を具体的に見ていただけるようにします ビジネスの観点から見るとその価値はプロジェクトのスピードに現れます 00:18:29.020 --> 00:18:35.640 サイクルの短縮は単に開発者の満足度だけの問題ではありません 今回のリリースで機能を実装するか数四半期先送りするかの分かれ道となります 00:18:35.640 --> 00:18:44.600 ハックやリグレッションがバックログに残りにくくなるため技術的不採にも影響します フローが円滑になれば前のスプリントの修正作業に戻ることなくチームは着実に前進できます 00:18:44.600 --> 00:18:50.640 その一貫性が積み重なることでトラブル対応が減り長期的にはより強固なデリバリーが可能になります そこには人間的な要素も存在します 00:18:50.640 --> 00:18:57.940 エラーの追跡に1日を費やせばどんなエンジニアでも疲れ果ててしまいます 疲労が溜まると洗練された設計は難しくなり細部を見落としミスが入り込みます 00:18:57.940 --> 00:19:05.880 機械的な修正をエージェントに任せることで開発者はより長く集中力を維持できます その余裕が生産性と品質の両方を向上させます 00:19:05.880 --> 00:19:15.460 繰り返される摩擦にすり減らされることがなければ広い視野で考えより効果的に計画を 立てられます実際の違いはこのように現れます複数のバインディングやサービス統合を含む 00:19:15.460 --> 00:19:23.860 新しいアジュール関数は自力では丸2日かかるかもしれません 設定やテスト不整合な参照の修正など作業は長引く一方です 00:19:23.860 --> 00:19:32.360 エージェントの助けを借りれば同じ関数を半日で作成できます 手抜きをするからではなくファイル間の設定や調整が初回で正確に決まるからです 00:19:32.360 --> 00:19:38.300 やり直しや無駄な労力が省かれスケジュールが短縮されます 一部の開発者は最もな懸念を口にします 00:19:38.300 --> 00:19:44.320 ai に保守を頼ることで自分自身のスキルが鈍るのではないかとその視点は何が実際に変化しているのかを見落としています 00:19:44.320 --> 00:19:50.160 反復的な設定を肩代わりさせることは専門性を弱めるのではなく判断力が生きる設計やアーキテクチャのために温存させるのです 00:19:50.160 --> 00:19:58.680 実際には軌道修正にエネルギーを浪費する代わりにより高度な問題解決に取り組む余地が生まれます 試してみた方はスプリントで何時間取り戻せたかコメントで教えてください 00:19:58.680 --> 00:20:06.740 興味深い回答は今後の動画で取り上げさせていただきます 他チームの体験を聞くことでデモや例を超えた真の価値を誰もが理解できるようになります 00:20:06.740 --> 00:20:14.640 ただし注意点として自動化は役立ちますが安全性は依然として重要です エージェントが作成した変更は必ずテストを実行しコードレビューを行ってください 00:20:14.640 --> 00:20:21.600 煩雑な作業が減ることは信頼しつつもこれまで通りのガードレールは維持しましょう スピードの差が利益を生むのは品質が一定に保たれている場合だけです 00:20:21.600 --> 00:20:31.020 強力なテストと賢明な pr レビューが壊れやすい自動化からリリースパイプラインを守ります 真の成果はコードを早く書くことではなくより優れたソリューションを生み出すためのスペースを確保することに 00:20:31.020 --> 00:20:33.180 あります 疲労を減らしより少ない