マイクロソフトのAI責任者:二人の罠

マイクロソフトのAI担当エグゼクティブ副社長が、多くの人々がAIを誤った使い方をしている理由を明らかにし、彼らを2つの異なるグループに分類しました。新しいソフトウェア開発時代において生き残り、繁栄するために必要な文化的シフトを探ります。

Stork.AI
Hero image for: マイクロソフトのAI責任者:二人の罠
💡

TL;DR / Key Takeaways

マイクロソフトのAI担当エグゼクティブ副社長が、多くの人々がAIを誤った使い方をしている理由を明らかにし、彼らを2つの異なるグループに分類しました。新しいソフトウェア開発時代において生き残り、繁栄するために必要な文化的シフトを探ります。

マイクロソフトの新しい「エージェントファクトリー」が登場しました

マイクロソフトは今年、AIの組織図を静かに再構築しました。そして、新たな回路はコアAIを通じて流れています。このチームは、以前は別々の宇宙であった開発者部門とクラウドインフラグループを融合させています。サティア・ナデラに直接報告するジェイ・パリクは、Visual StudioやGitHubスタイルのツールから、大規模言語モデルをトレーニングし運用するAzureクラスターまで、すべての責任を持っています。コアAIは、分断されたチーム間で機能を行き来させるのではなく、すべての人が基盤にするスタックを構築するという一つの使命を持った単一のプロダクトグループとして機能しています。

パリクはそのスタックを「進化している」と表現していますが、輪郭はすでに明確です。最上部には、ソフトウェアの作成、テスト、出荷の方法を再構築するAIネイティブツールがあり、開発ライフサイクル全体にコパイロットが組み込まれていて、IDEに取り付けられるのではありません。その下には、マイクロソフトのいわゆる「エージェントファクトリー」であるファウンダリーが存在し、企業がデジタル従業員のように振る舞うAIエージェントを設計、展開、監視するためのプラットフォームです。

Foundryは単なるホスティングレイヤーではなく、スタックの中心的な存在です。ここでは、企業がエージェントを内部データに接続し、それらをツールやAPIに結びつけ、従来のダッシュボードよりもセキュリティオペレーションセンターに近い観測可能性を持たせて本番環境でそれらが動作するのを見守ることができます。マイクロソフトは、Foundryが開発者が生のモデルに悩むのをやめ、高次の振る舞いを構成し始める場所になることを望んでいます。

これらすべての基盤には、AIが決定論的でなく、初めから危険である可能性があるという前提に基づくセキュリティと信頼の層があります。事後監査の代わりに、Core AIは、エージェントがツールとデータにアクセスする層でポリシーコントロール、ガードレール、およびコンプライアンスのフックを組み込んでいます。目的は、企業の最も敏感なワークフロー内で計画を立て、ツールを呼び出し、自律的に行動する推論システムに「デフォルトでセキュア」を適用することです。

最後に、マイクロソフトは柔軟なデプロイメントのためのスタックを設計しています:クラウドファーストですが、クラウドのみではありません。同じプログラミングモデルは、Azureリージョン、規制された主権クラウド、そして工場、小売店舗、またはフィールドデバイスにおけるエッジハードウェアにまたがる必要があります。クリエイターにとって、その抽象化こそがポイントです。GPU、CPU、またはデータが実際にどこに置かれているかに関わらず、エージェントがどのように振る舞うかの1つのモデルです。

オフィスに完全復帰する真の理由

イラスト:オフィスに完全復帰する真の理由
イラスト:オフィスに完全復帰する真の理由

マイクロソフトの新しいAIブレイントラストは、週5日オフィスに戻ってきますが、その動きは2019年へのノスタルジーからではありません。コアAIのエグゼクティブバイスプレジデントであるジェイ・パリクは、モデル、ツール、MCPのようなプロトコルが毎週変わるとき、分散チームは遅延したフィードバックループや逃した偶然の発見に多くの時間を失うと主張しています。

パリクの提案はシンプルです。AIは指数関数的に進化しており、人間もそれに追いつくためには同じくらい速い学習ループが必要だと言います。彼は、そのためには規模に応じた密な対面でのコラボレーションが不可欠であり、コーチング、デバッグ、実験が継続的に行われるべきで、Teamsでの1時間の予定のブロックに限られるべきではないと述べています。

マイクロソフトのAIフロア内では、たった一つの気軽なコメントが正式なトレーニングと同じくらい価値があることがあります。エンジニアが、テストスイートの実行時間を数時間から数分に短縮した新しいCopilotプロンプトパターンや、エージェントを通じてツールを連携させるためのトリックを指摘すれば、サポートチケットの解決時間が半分になることから、瞬く間にポッド全体がレベルアップします。

そのマイクロレッスンは、Slackやメールでは同じ忠実度で伝わることはめったにありません。廊下では、誰かがノートパソコンを手に取り、プロンプトを再生し、サポートを調整し、リアルタイムで結果が変化するのを見ながら、他の3人がコンテキストウィンドウ、基データ、または安全策について意見を交わすことができます。

パリクは、それを発見が社会的で継続的である「ライブラボ」を構築することとして位置付けています。個々の人が静かにコパイロットで実験を行うのではなく、チームが集まって難題に取り組みます:エージェントが本番データに対して安全に操作する方法、金融ワークフローにおける幻想を減少させる方法、エンジニアでない人々が実際に維持できるプロンプトをデザインする方法です。

逆説的な部分は、デジタルファーストのツールを習得することが今や物理的な存在に大きく依存していることです。パリックの考え方では、AIが高性能であればあるほど、人対人のパターン共有がより重要になるのです。なぜなら、可能なワークフローの範囲が爆発的に広がり、どんな文書セットも追いつけなくなるからです。

リモートワークは、安定して理解されたシステムにはまだ意味があります。しかし、Microsoftの最先端のAIスタック—モデル、SDK、およびデプロイメントターゲットが数ヶ月でクラウドからエッジデバイスに移行するような環境において—パリク氏は、真の生産性の向上要因は帯域幅ではなく、近接性であると賭けています。

それは文化の戦争であり、技術の競争ではない。

文化が、計算ではなく、ジェイ・パリクのカレンダーを支配している。彼は、フォーチュン500の経営者との会話の約90%が、モデルサイズ、GPUの数、またはデータセンターの面積とは無関係であり、日々の業務の進め方を変えることに対する組織の意欲に関するものであると述べている。

マイクロソフトは、その変革のために自らを実験台として活用しようとしています。Core AI内で、パリクは「Thrive Inside」と呼ばれるプログラムに注目しています。これは、従業員が時間をどのように使っているかを追跡し、その後「ビジネスを運営する」際の煩雑な業務—ステータスレポート、調整業務、手動ドキュメント—をCopilotスタイルのエージェントで解消します。これらのエージェントは、自動的に要約、ドラフト、業務のルーティングを行います。

目標はシンプルで厳しいものに聞こえる:時間を取り戻し、それを製品に再配分すること。エンジニアやプロダクトマネージャーが運用業務に時間を費やす代わりに、Thrive Insideは週の大部分を新機能の設計、実験の実施、顧客との対話に充てることを目指している。まさにAIがまだ彼らのためにできない仕事なのだ。

その再構成は、チームがソフトウェアを構築する方法を変えます。パリックは、単一のプロトタイプを手作業で作成し、フィードバックを待つのではなく、チームが同時に5つのAI生成バリエーションを立ち上げ、社内または社外のユーザーに提供し、実際にどれが受け入れられるかを見ることを望んでいます。

迅速で並行したプロトタイピングは、リーダーシップがより乱雑なパイプラインを受け入れた場合にのみ機能します。これは、ユーザーの前に出される未完成のアイデアが増え、迅速に中止される実験が増え、データが示す内容に基づいて柔軟に変化する製品ロードマップを意味します。決定したのは前四半期の運営委員会ではなく。

パリクは、そこでほとんどの企業が行き詰まると主張しています。予算の承認が下り、ベンダーが並び、タレントも確保できるのに、企業はAIに根ざした働き方に基づいてワークフローや承認チェーン、インセンティブ構造を再編成することを拒否しています。

したがって、本当の競争優位性は、OpenAIのようなモデルやパートナーシップへのアクセスではなく、企業がMicrosoftがCore AIで提案している垂直統合されたAIスタックに合わせて自社のオペレーティングシステムを再設計するかどうかにかかっています。

あなたの職種は時代遅れになりつつあります。

「プロダクトマネージャー」や「フロントエンドエンジニア」といった職種名は、プロンプトが数秒でその境界を越えることができると、不安定に見え始めます。マイクロソフトのコアAIグループは、理由があって「開発者」とではなく「ビルダー」という言葉を使います:その仕事は今やアイディアから展開までの連続体に広がっており、AIが従来の役割の間を埋めています。ガードレールは依然として重要ですが、分野間の壁は崩れつつあります。

かつてJiraとPowerPointに没頭していたプロダクトマネージャーは、今やスタックトレースをGitHub Copilotやローカルモデルに貼り付けてパッチを依頼することで、低リスクのバグを修正できます。彼らはユニットテストを生成し、パイプラインを実行し、エンジニアが空くのを待つことなくホットフィックスを出荷することができます。これにより専門家が置き換えられるわけではありませんが、誰が本番コードに触れられるかが根本的に変わります。

一方、Figmaを一度も開いたことのないシステムエンジニアやSREが、今ではプロンプトを使ってUIフローを描くようになっています。彼らはデータセンター全体のGPU利用率を示すダッシュボードを説明すると、Visual Studio CodeのCopilotがReactコンポーネントやTailwind CSS、さらにはサンプルのテレメトリグラフを生成します。デザイナーが後でそれを洗練させることができますが、最初のインタラクティブプロトタイプは数週間ではなく数時間で完成します。

作業はサイロ間のリレー競技のようではなく、共有のキャンバスのようになります。一人の人ができること: - UXコピーを作成する - APIスタブを生成する - ロギングを設定する - 機能フラグの背後で実験を出荷する

すべてが同じAI駆動のツールチェーンを使用しつつ、スケール、安全性、仕上げのために専門家を引き入れています。

マイクロソフトの「エージェントファクトリー」ビジョンは、これをスタックに組み込んでいます。同じファウンドリプラットフォームが、クラウドとエッジの両方でエージェントの構築、展開、観察をサポートします。この統一されたパイプラインは、クロスファンクショナルチームが一緒に座り、プロンプトを繰り返し検討し、スキャフォールディングコードを微調整し、短いループで本番環境にプッシュすることを促進します。ハンドオフが少ないほど、要件の見落としが減り、フィードバックが早くなります。

融合は、より奇抜で野心的なアイデアも解放します。セキュリティエンジニアは自己修復型のインシデントボットをプロトタイプできます。ファイナンスアナリストは予測マイクロサービスを構築できます。誰もが構築、展開、運営できるとき、職種は最も興味深い質問を持っている人や、その質問に答えるエージェントを実行できる人の方が重要になります。

AIに驚かされていますか、それともイライラしていますか?

イラスト: AIに驚いていますか、それともイライラしていますか?
イラスト: AIに驚いていますか、それともイライラしていますか?

ジェイ・パリクは、出会うほとんどの人が二つのAIグループに分かれると言います。グループ1は、1つの良いCopilotの応答を聞いて「わあ、これは魔法だ」と言って去ります。グループ2は、同じ応答から「なぜこれもX、Y、Zを行わなかったのか」とつぶやきながら去り、すぐに実験を始めます。

グループ1はAIを新しいガジェットのように使っています。短いメールを貼り付けて要約を求め、週に一度スライドを生成することもありますが、最初の奇妙な回答や幻覚に遭遇するとすぐにやめてしまいます。彼らのスキルの向上はほとんどなく、期待が低く、使用が浅いためです。

グループ2は、AIを業務のオペレーティングシステムとして扱います。彼らはプロンプトを連携させ、会社のデータを接続し、エージェントに多段階プロジェクトを処理させます:契約書のドラフト、レガシーコードのリファクタリング、生のCSVからの顧客レポートの作成。彼らはエラーメッセージの中で生き、失敗から学び、モデルが月ごとに改善されるにつれて難易度を常に引き上げています。

パリク自身のチームは、マイクロソフト内で明確にその第二のグループに属しています。コアAIエンジニアたちは対面で集まり、Copilotがテストハーネスを作成したり、テレメトリーダッシュボードを生成したり、膨大なログを分析したりする方法を模索しています。彼らは何かを試し、それが失敗するのを見守り、プロンプトやツールを変更して再挑戦します—なぜなら、そうすることでパリクが「指数関数的な軌道」と呼ぶこの技術の進化に乗り続けることができるからです。

自己チェックの時間: 過去1週間に、AIツールを実際にどれくらいの時間使いましたか?「いくつかのプロンプト、合計でおそらく10分」と答えた場合、あなたはグループ1に属します。1日に何時間使っているかを計測し、AIに基づいて再構築した具体的なワークフローが少なくとも3つ名付けられる場合は、グループ2に向かっています。

少し難しい質問を自問してみてください: - 効いたプロンプトやテクニックのドキュメントを作成していますか? - AIをカレンダー、コードリポジトリ、CRM、またはデータウェアハウスに接続しましたか? - モデルを過信して仕事で何かを壊してしまい、その後プロセスを調整しましたか?

グループ1は、AIが改善されることで自動的に限界生産性の向上を得るでしょう。グループ2は静かに職務内容を置き換えます。パリクが従来の役割があいまいになっていると言うとき、彼はAIを利用して同時に3つの仕事、すなわちエンジニア、アナリスト、そしてプロダクト思考者を融合させた「ビルダー」として働く人々について話しています。

キャリアは今、あなたがどの曲線を選ぶかにかかっています。驚くことは任意です。フラストレーションを感じ、迅速に学ぶことは必須です。

AIパワーユーザーのマインドセット

グループ2のユーザーは、AIを新しいプログラミング言語のように扱い、平凡であることを拒否します。彼らはGPT-4o、Claude、Gemini、オープンソースモデルを横並びでテストし、コードスニペットのようにプロンプトを交換し、どのシステムが長文の推論や構造化された出力を最も得意とするかを心の中で基準にしています。彼らはベンダーのマーケティングを信頼せず、自らの実験を信頼します。

習慣はほとんど執着心のように見えます。彼らはプロンプトを記録し、失敗を追跡し、作業フローが日常的に実行できるほど信頼性があるまで反復します。モデルが誤った出力をした場合、彼らは肩をすくめてそのまま進むのではなく、プロンプトを再設計し、ツールを追加したり、モデルを変更したりして、その解決策を文書化します。

裏で、彼らは静かにコンテキストエンジニアリングを学んでいます。彼らは雰囲気ではなく、トークンやリトリーバルで考えています:システムプロンプトに何を入力し、ユーザー入力には何を残し、ベクターストアに何を移すのか。彼らはスキーマを設計し、文書をチャンクし、異なるコンテキストウィンドウや温度がレイテンシーやコストにどのように影響するかをテストしています。

彼らはまた、評価指標の言語を話し始めます。「これが良い感じ」と言う代わりに、以下の点を追跡します: - 20〜50のテストケースにおけるタスク成功率 - タスクあたりのレイテンシとコスト - エラータイプ:ハルシネーション、フォーマット、セーフティ、ツールの誤用 彼らはPythonで小さな評価ハーネスを構築するか、市販の評価ツールを使用して、フィーリングに基づくエージェントを製品に投入するのを避けます。

そこから、多くの人がファインチューニング強化学習に進みます。彼らはサポートチケットやコードベースに対して、小規模なドメイン特化型のファインチューニングを行い、それを純粋なプロンプティングと比較します。また、内部エージェントに対する人間からのフィードバックを用いた強化学習にも挑戦し、ツール使用の規律や企業ポリシーの遵守といった行動に報酬を与えます。

フラストレーションは彼らのデフォルトの状態であり、最良のシグナルでもあります。CopilotやChatGPTの限界に何度もぶつかるとき、それはあなたの野心が「仕事のオートコンプリート」を超え、システム設計へと移行したことを意味します。これらの壁にぶつかることで、モデルが実際にどのように機能するのかを学ぶことを余儀なくされます。

グループ1からグループ2への移行は、意図から始まります。毎日30〜60分を確保して以下を行いましょう: - モデル間でA/Bテストを実施する - 週に1つの再利用可能なプロンプトまたはエージェントを構築する - 失敗とその変更点を記録する Jay Parikh - Microsoft Build のようなリソースは、このマインドセットがスケールで向かっている方向を示しています。あなたの仕事は、その実験ループを縮小版で再現することです。

コパイロットを超えて:あなたはすぐにエージェントの軍隊を管理することになります

Copilotはただのチュートリアルレベルに過ぎません。Jay ParikhのCore AIグループはすでに異なるゲームをプレイしており、互いにコミュニケーションを取る専門的なエージェントの群れを調整しています。高度なチームは単一のモデルに「コードを書いて」と頼むのではなく、プランナー、コーダー、テスター、レビュワーを組み合わせてシリコン上で動作するミニチュアソフトウェア会社を構築しています。

マイクロソフト内部では、最も先進的なグループのいくつかが、ソースコードの1行にも触れないことを避けています。エンジニアたちは、高レベルの仕様、制約、インターフェースを定義し、その設計図をマイクロソフトの内部「ファウンドリー」エージェントファクトリープラットフォーム上で稼働するエージェントのスタックに渡すワークフローを説明します。人間の注意は、構文をミクロマネジメントするのではなく、行動やガードレールを形作る方向に移行します。

このスタックの重要な要素は検証エージェントです。AI生成コードを人間のレビューキューに放り込むのではなく、検証エージェントは自動的にテスト、静的分析、およびポリシーチェックを実行し、その後、構造化されたフィードバックをコーディングエージェントに返します。このループは、生成 → 検証 → 再生成という形で、人間が差分を見る前に何度もサイクルします。

そのフィードバックは単に「テストが失敗した」ということではありません。検証エージェントは、欠落しているエッジケース、パフォーマンスの後退、セキュリティポリシー違反、またはAPI契約の破損を指摘することができます。それに対してコーディングエージェントは、その機械のフィードバックを文脈として利用し、独自のプロンプトや戦略を更新して問題を自律的に修正します。人間はループが停滞したときに介入し、すべての trivial bug が発生したときに介入するわけではありません。

パリクのチームは、エージェントが組立ラインを所有するソフトウェアファクトリーを効果的に運営しています。一人のエージェントは要件の拡張を担当し、別のエージェントはサービスを整備し、三人目は可観測性を接続し、他のエージェントはドキュメントやデプロイマニフェストに特化しています。各エージェントは同僚に向けてツールやAPIを提供し、リポジトリを静的なファイルの山ではなく、生きたマルチエージェントシステムに変えています。

その世界におけるあなたの役割は、「開発者」とはほど遠く、「工場長」のように見えます。どのエージェントを起動させるか、どの能力を与えるか、データへのアクセスをどの程度制約するか、どの検証ゲートを適用するかを決定します。実際の影響力は、これらのエージェント軍を設計し、スケジュールし、管理できる人々に移行しています—なぜなら、キーボード業務は急速に最も重要でない部分になりつつあるからです。

見えざる戦争:エージェンティックな世界における安全保障

イラスト:見えざる戦争:エージェント的世界における安全保障
イラスト:見えざる戦争:エージェント的世界における安全保障

非決定論的なAIエージェントは単に不正行為をするだけでなく、まったく新しい攻撃面を生み出します。従来のアプリは固定されたコードパスに従いますが、エージェントは計画し、ツールを探索し、即興でトラブルに巻き込まれることがあります。これは、誰も明示的に悪い行動をプログラムしていない場合でも起こります。この予測不可能性は、再現可能で監査可能なワークフローを基に築かれた数十年のセキュリティの前提を覆します。

従来の企業セキュリティは静的なチェックリストに依存しています:パッチレベル、役割ベースのアクセス制御、コンプライアンスの証明書。エージェントシステムはそのモデルを超えて、単一のエージェントがリアルタイムでAPIを連鎖させ、知識ベースを横断し、SaaS、オンプレミス、エッジ環境全体でアクションを統合することが可能です。もはやエンドポイントを守るだけではなく、発生する行動を守っています。

エージェントのセキュリティは、一回限りのペネトレーションテストというよりも、継続的な航空交通管理に似ています。企業には以下が必要です: - ツールやデータに対する細かく、取り消し可能な権限 - エージェントの計画の各ステップを評価するポリシーエンジン - 疑わしい行動の連鎖を停止させるためのランタイム「サーキットブレーカー」 これらすべては監査人が午前3時17分にAIがなぜそのような行動をとったのかを尋ねる際に、可視化され、ログに記録され、説明可能でなければなりません。

パリクは常に一つのポイントに戻ります:セキュリティと信頼は後から付け加えることはできません。エージェントが自律的にCRM、ERP、コードリポジトリに接続できる場合、誤設定は単一のバグの問題ではなく、影響範囲の問題になります。ガードレール、ガバナンス、レッドチーミングは、モデル選択やプロンプトの足場から展開や監視まで、AIスタックのすべての層に存在しなければなりません。

MicrosoftのFoundryプラットフォーム、いわゆる「エージェントファクトリー」は、企業のためにその原則を武器化する場所です。Foundryは、ポリシーを意識したオーケストレーションを強化し、ツールとデータへのアクセスをデフォルトで拒否し、Azure、オンプレミス、またはエッジで動作する数千のエージェントに対して深い可観測性を提供することを目指しています。この提案はシンプルですが強力です。エージェントの軍隊を解き放つつもりなら、Foundryの役割は、単独の不正または侵害されたエージェントが内部のSolarWindsに変わるのを防ぐことです。

革命を推進する:データセンターとエネルギー

フェアウォーターは、マイクロソフトの最新のAIデータセンターキャンパスで、AIブームがモデルの問題だけでなくインフラの問題でもあることを静かに認めています。CopilotやGPT-4クラスのモデル、そして多数のエージェントを訓練し運用することは、もはや単なる巧妙なアーキテクチャに依存しているわけではなく、コンクリート、鋼鉄、そしてメガワットに依存しています。マイクロソフトは需要に応えるために、毎年数百億ドルを新しいデータセンター、カスタムネットワーキング、そして液体冷却に投資しています。

ダークGPU」についての話 - 高性能アクセラレーターがアイドル状態にあるという主張 - は、Jay Parikhが現場で説明する内容と対立しています。キャパシティは存在しますが、地域、SKU、ネットワークトポロジーごとに分散しており、しばしばハイパースケールのトレーニングランのために数ヶ月前から予約されています。実際のボトルネックは、電力供給、冷却の制約、そして高帯域幅・低遅延の相互接続を適切なラックに届けることにあり、使用されずにほこりをかぶったH100のパレットにはありません。

エネルギーは今や厳しい限界として浮上しています。AIデータセンターはすでに年間数十テラワット時を消費しており、電力会社や規制当局からの業界予測は、今後10年間でデータセンターの負荷が二桁のパーセンテージで成長すると示しています。米国や欧州のグリッドオペレーターは、大規模なAIキャンパスがそれぞれ1~5GWを必要とする可能性があり、これは中規模の都市に相当すると警告しており、送電および発電の長期的なアップグレードを強いられています。

マイクロソフトの答えは単に「データセンターをもっと建設する」ことではなく、「インテリジェンスをエッジに移動させる」ことです。パリクのチームは、エージェントアプリケーションがクラウド、地域データセンター、オンプレミスインフラストラクチャ、エッジデバイスの4つのプレーンで実行できるプログラミングモデルを設計しています。この分散により、クラウドへの往復が減少し、帯域幅が削減され、最も電力制約のある施設から一部の計算が移転されます。

エッジファーストエージェントは、異なる種類の効率性の物語を生み出します。工場のフロアエージェントがGPUを装備したゲートウェイでローカルに推論できる場合、クラウドは生のセンサーの洪水ではなく、要約された状態のみを認識します。マイクロソフトの「エージェントファクトリー」という広範なビジョンは、ソフトウェアファクトリーからエージェントファクトリーへ:マイクロソフトが開発を再考している方法で詳述されており、この連続体に依存しています:ハイパースケールデータセンターでの重いトレーニング、クラウドでのオーケストレーション、エッジでの迅速で電力意識のある推論。

AI時代のためのアクションプラン

ChatGPTやCopilotをマジックトリックのように扱うのはやめましょう。彼らを、あなたがスタッフレベルのオペレーターに育てることを決意した、期待外れのインターンのように扱ってください。もしまだ、大規模言語モデルがメールを書くことに「驚いている」のであれば、期待値を上げましょう:動作するコード、複数ステップの分析、エンドツーエンドのプロジェクト草案を求め、それが失敗したときには再度プレッシャーをかけましょう。

毎週の始まりは、一つの面倒なタスクを選び、「Group 2 はAIを使ってここで何をするだろう?」と自問することから始めましょう。モデルを3回か4回繰り返して試み、異なるモデル(GPT-4、Claude、Gemini)を使い、実際のツール—あなたのIDE、カレンダー、CRM、またはデータウェアハウス—を結びつけます。成果をもって自分を測定しましょう:節約した時間、修正したバグ、実施した実験によって。

クロスファンクショナルな学びは、今や生存スキルとなりました。エンジニアであれば、GitHub CopilotやGPT-4を使ってFigmaで簡易なUXプロトタイプを構築し、ローンチブリーフを作成しましょう。PMであれば、AIに助けてもらいながら失敗しているテストのデバッグを行い、パッチを生成し、プルリクエストを開きましょう。デザイナーは、モデルを利用してSQLクエリや基本的なテレメトリダッシュボード、さらには脅威モデルを作成することができます。

システムで考え、プロンプトではありません。難しいプロジェクト、たとえば新しい内部ツールの立ち上げを考え、以下のエージェントに分けてみましょう: - リサーチエージェント:市場、競合、ユーザーインタビュー - アーキテクトエージェント:要件、図、トレードオフ - 実行エージェント:コード、テスト、デプロイスクリプト - レッドチームエージェント:セキュリティ、悪用、失敗モード

次に、彼らがどのように作業を引き継ぎ、お互いをレビューし、あなたにエスカレーションするかをスクリプト化します。

社内では、単なるツールではなく、文化について語る人になりましょう。チームミーティングで短い「AIドリル」を行い、週次の投稿で具体的な成功事例や失敗事例を共有し、リーダーに実験を奨励するよう働きかけましょう—たとえそれが失敗に終わったとしても。もしマイクロソフトのコアAIグループが維持するために対面でのコラボレーションを必要としているなら、あなたのチームも少なくとも生きた、息をするAIプレイブックを必要としているでしょう。

よくある質問

マイクロソフトの新しいコアAIチームとは何ですか?

新たに統合された部門で、EVPのジェイ・パリクが率いており、開発者ツール、コアインフラストラクチャ、AIプラットフォームを統合して、AIエージェントとアプリケーションを構築、デプロイ、セキュリティするための統一された「スタック」を作り出しています。

なぜジェイ・パリクのチームはフルタイムでオフィスに戻るのか?

パリクは、AIの急速で指数的な発展のペースが対面でのコラボレーション、コーチング、学びを必要とすると信じています。彼は、チームが一緒に学び、適応することでより速く進化するため、AIイノベーションの最前線に留まるために重要であると主張しています。

AIはソフトウェア開発者の役割をどのように変えているのか?

AIはエンジニアリング、プロダクト、デザインといった役割の境界を曖昧にしています。これにより、個人は従来の領域の外でタスクを遂行できるようになり、コーディングを書くことからAIエージェントを調整し、文脈を設計し、成果を検証することに焦点が移っています。

ジェイ・パリクが説明するAIユーザーの2種類は何ですか?

グループ1はAIに簡単に驚かされ、あまり使用せず、期待値も低いです。グループ2は複雑なタスクに対してAIを常に使用し、その限界に不満を感じることが多く、積極的にその可能性を広げているため、急速に学習を進めています。

🚀Discover More

Stay Ahead of the AI Curve

Discover the best AI tools, agents, and MCP servers curated by Stork.AI. Find the right solutions to supercharge your workflow.

Back to all posts