English
Français
日本語
繁體中文
このページの内容は、サードパーティサービスによって自動翻訳されています。
市場は間違ったゴールに向かっているのかもしれない
現在、業界の多くは、あるシンプルな問いに注目しているように見えます。それは、「どれだけ速くエージェントを作れるか」ということです。
その魅力は理解できます。エージェントは具体的で、デモでも見栄えがよく、進歩をわかりやすく示すことができます。しかし、特にエンジニアリングにおいて、スピードが最初に解決すべき問題なのか、私は疑問に思っています。その下にある、より難しい基盤が整う前に、エージェントのレイヤーを構築しようと急ぎすぎているのかもしれません。
自律性が可能だからといって、エンジニアリングに自律性が必要なわけではありません。必要なのは、製品データ、変更プロセス、トレーサビリティ、権限、そして顧客固有の仕事の進め方がすべて重要となる、実際のエンジニアリング業務に確実に参加できるAIです。エージェントはデモでは印象的に見えても、その現実に直面すると十分に機能しない可能性があります。
この市場がどこへ向かっているのかを考えれば考えるほど、私たちは問題の目に見える部分に集中しているのではないかと思うようになりました。エンジニアリングAIに欠けているのは、新しいモデルのリリースでも、より多くのエージェントでもありません。人々が実際に仕事をするために必要なデータとコンテキストへの、役割に応じたアクセスです。
エンジニアリングに不足しているのは知識ではない
ほとんどのエンジニアリング組織には、すでに豊富な専門知識があります。しかし、コンテキストへのアクセスとなると話は別です。
要件はあるシステムに存在し、製品構成は別のシステムに存在するかもしれません。変更記録、品質履歴、製造上の制約、サプライヤー情報、市場からのフィードバック、プログラム上の意思決定などがライフサイクル全体に分散し、それぞれについて、誰が閲覧または変更できるかを定める異なるルールが適用されていることもあります。
AIが機能しなければならないのは、まさにこのような環境です。そして、汎用AIがエンジニアリングチームの期待するレベルの信頼性を実現するのに苦労する理由の一つでもあります。
したがって、問うべきなのは、AIシステムが知的に聞こえる回答を生成できるかどうかではありません。この人、このタスク、この瞬間に必要なライフサイクルのコンテキストを見つけられるか。適切な権限のもとでそれを実行できるか。そして、エンジニアは情報源に戻り、その回答がどこから来たのかを理解できるか。
こちらのほうが、はるかに実践的な評価基準です。これらがなければ、AIによる支援はすぐに新たなノイズの源になってしまいます。
エージェントの急増は別の問題を生み出す
エージェントの数そのものが問題の一部になる時点も近づいています。
エンジニアには、新しいツールを評価するための時間が無限にあるわけではありません。ほとんどのチームはすでに複雑なテクノロジー環境で仕事をしており、次々と登場する新しいエージェントを一つずつ評価するよう求めるのは現実的ではありません。エージェントが増えるにつれて、課題は変わります。エージェントを見つけることは簡単になります。一方で、どのエージェントに注目する価値があるのかを判断することは難しくなります。
そのため、私は選別が導入と同じくらい、あるいはそれ以上に重要になると考えています。
エンジニアリングチームには、信頼できるエンジニアリング情報へのアクセスを本当に改善するツールと、単に新しいインターフェースを追加するだけのツールを見分ける方法が必要になります。その違いは必ずしも明白ではありません。実際の業務の中で見えてくるでしょう。エージェントがアクセスできるコンテキストの質、そのアクセスを管理する仕組み、そして出力がより良い意思決定につながるかどうかに表れます。
そのような市場では、熱意よりも判断力が重要になります。
役割は機能ではなく、アーキテクチャの一部である
エンタープライズAIについて広く語られる中で見落とされがちなのは、エンジニアリング業務が実際にはどれほど役割に依存しているかという点です。
一つの製品問題を例に考えてみましょう。システムエンジニアは、その背景にある要件を理解したいと考えるかもしれません。製造エンジニアなら、それが下流の製造現場にどのような影響を与えるのかを知りたいでしょう。品質部門は、その問題を特定の変更や過去の事象まで追跡する必要があるかもしれません。プログラムマネージャーは、同じ問題を納期リスクや顧客への影響という観点から見ている可能性があります。
同じ製品。同じ根本的な問題。しかし、問いはまったく異なります。
そして重要なのは、これらの人々が必ずしもまったく同じ情報にアクセスできるべきではないということです。
だからこそ私は、役割をパーソナライゼーション機能ではなく、アーキテクチャ上の考慮事項だと考えています。役割は、情報の関連性、権限、根拠、そして最終的にはAIが伝える内容を信頼できるかどうかに影響します。
エンジニアリングAIが機能するためには、こうした境界に適合しなければなりません。不完全または不適切なコンテキストに誰もがより速くアクセスできるようにしても、組織が賢くなるわけではありません。不完全な情報がより速く広がるだけです。
本当の機会は、エージェントを大量生産することではない
ここでも、市場は成功の意味を見直す必要があると私は考えています。
汎用エージェントを大量に用意し、その用途を顧客自身に探してもらうという方法には、それほど魅力を感じません。もっと興味深いのは、実際のエンジニアリング業務のどこでAIが意味のある違いを生み出せるのか、そしてその能力を顧客のプロセス、データ、ガバナンスに合わせてどのように形作るべきか、という問いです。
設計の前提となる標準的なエンジニアリング環境が一つだけ存在するわけではありません。
製品構成は企業ごとに異なります。変更プロセスも進化します。システムは長年にわたって蓄積されていきます。データモデルには、数え切れないほどのビジネス上、エンジニアリング上の意思決定の歴史が刻まれています。同じコアプラットフォームを使用する2社であっても、その使い方は驚くほど異なる場合があります。
AIによって、こうした違いがなくなるわけではありません。むしろ、ある意味では違いがより明確になります。
だからこそ私は、エージェントを画一的な製品とは考えていません。むしろ、実際のワークフローの中でAIに何ができるのかを示す実践的な例、つまり可能性を証明するものとして有用です。ただし、その体験は利用する組織に合わせて適応させる必要があります。
プラットフォーム戦略が重要になるところ
これはプラットフォーム戦略にも影響します。
最も有利な立場に立つ企業は、必ずしも最も壮大なAIのストーリーを語る企業ではないかもしれません。非常に具体的で、顧客ごとに形作られたエンジニアリング環境で運用する方法をすでに理解し、その適応力をAIにも持ち込めるプラットフォームが優位になると私は考えています。
顧客が構成可能なプラットフォームにすでに何を期待しているかを考えてみてください。複雑な製品ライフサイクル、さまざまなプロセス、進化するデータモデル、そして特定の組織が実際にどのように業務を行っているかに対応できなければなりません。なぜAIだけが違うのでしょうか。
AIは、すべての上に置かれる固定的なレイヤーとして導入されるべきではありません。その環境の中で機能し、適切な場面でエージェントを活用して、ガバナンスされたライフサイクルのコンテキストを、人々が行動に移せるものへと変えるべきです。
このように考えると、エージェントそのものの重要性は低くなります。重要なのは、エージェントが責任を持って何にアクセスできるのか、そして人が何を実行するのを支援できるのかです。
エンジニアリングソフトウェアプロバイダーにとって、これははるかに持続性のある立ち位置だと思います。議論の焦点をAIのパッケージ化から、いずれ顧客が必ず尋ねることになる問いへと移すからです。より良い意思決定に役立ったか。有意義な時間を節約できたか。信頼できるか。本当に自社の環境で機能するのか。
デジタルスレッド戦略は置き換えられるのではなく、試されている
AIはまた、長年にわたるデジタルスレッド戦略を、非常に実践的な形で試すことになります。
長い間、デジタルスレッドをめぐる議論の中心は「つながり」でした。領域、チーム、システム、ライフサイクルの各段階をまたいで情報を結びつけることです。AIはその次の問いを投げかけます。情報がつながった後、意思決定が必要なときに実際にその情報を活用できるでしょうか。
ここからが興味深いところです。
エンジニアは、ガバナンスを回避することなく、自分の役割に関連する情報を取り出せるでしょうか。AIが生成した回答を、その根拠となる記録までたどることができるでしょうか。ライフサイクルのコンテキストは、その完全性を維持しながら、意思決定を支援できるほど迅速に提供されるでしょうか。
答えが「いいえ」であれば、問題がAIレイヤーにあると決めつけるべきではありません。AIは、基盤となるデータ戦略に以前から存在していた弱点を明らかにしているだけかもしれません。
だからこそ私は、AIとデジタルスレッドを相互に関連する課題だと考えています。AIは、ライフサイクルシステムに対して、情報を保存しガバナンスするだけでは不十分だという圧力をかけます。その情報は今や、誰かが必要とするその瞬間に利用できなければなりません。
より厳しい基準ですが、おそらくより有用な基準でもあります。
自律性より先に境界を定める
自律性は、イメージしやすい到達点であるため、AIに関する議論の中心になりがちです。しかし、エンジニアリングがそこから始められるとは思いません。
組織がAIにより大きな行動の自由を与える前に、どこに境界があるのかを把握する必要があります。どの役割が関係しているのか。システムはどのコンテキストを利用できるべきなのか。どのような権限が適用されるのか。何を追跡可能にする必要があるのか。
そして、エンジニアが回答に疑問を呈したとき、システムはその回答に至った根拠を示せなければなりません。
これは、完全に自律したエンジニアリングエージェントよりも野心的ではないように聞こえるかもしれません。しかし、私はむしろ逆だと考えます。実際のエンジニアリング業務の制約の中で確実に機能できるAIシステムを構築することは、誰かに意思決定の根拠を求められるまでは自律的に見えるシステムを構築するよりも、はるかに意味のある成果です。
独立性よりも先に、信頼性を確立しなければなりません。
エージェントの数ではなく、顧客固有の価値から始める
今後12～24か月の間に、さらに多くのエンジニアリングエージェントが登場すると予想しています。実際の問題を解決するものもあるでしょう。一方で、最初の目新しさが薄れれば、互いの違いを見分けるのが難しくなるものもあるでしょう。
エンジニアリングリーダーが、そのすべてを追いかける必要はありません。
より良い出発点は、すでに存在する環境を見ることです。適切な情報にアクセスできないために、人々はどこで時間を失っているのでしょうか。コンテキストの不足によって意思決定が遅れたり、リスクが生じたりしているのはどこでしょうか。AIはどこで役立つ可能性があり、その役割を責任を持って果たすためには、関係する人、プロセス、データについて何を知る必要があるのでしょうか。
こうした問いは、エージェントの数を数えるほど刺激的ではないかもしれません。しかし、実際の価値にははるかに近づきます。
その意味で、エージェントは可能性を示す有用な実証例です。役割に応じたアクセス、ライフサイクルのコンテキスト、顧客固有の構成が組み合わさることで何が可能になるのかを示すことができます。しかし、エージェントは手段であって、目的ではありません。
市場はこれからもエージェントに向かって競争を続けるかもしれません。それは構いません。ただし、エンジニアリングリーダーは、数が多いことを進歩だと取り違えるべきではありません。
際立つ企業は、必ずしも最も多くのエージェントを生み出す企業ではないでしょう。複雑で、ガバナンスされ、高度に固有化されたエンジニアリング業務の現実の中で、AIを役立つものにできる企業です。
だからこそ私は、役割に応じたデータアクセスという点に何度も立ち返ります。欠けているレイヤーは、モデルでもエージェントでもありません。
重要なのは、AIがエンジニアリング上の意思決定に実際に必要なコンテキストへ、その意思決定を行う人に応じてアクセスできるかどうかです。そして、その過程で、そもそも情報を信頼できるものにしていたガバナンスとトレーサビリティを失わないことです。
