2026年におけるAIエージェントとソフトウェア開発ツールの関係性を分析した動画である。Jiraなどの一見退屈なイシュートラッカーが、状態管理や権限、履歴といったエージェントにとって不可欠な要素を備えているため、自律型AIエージェントの基盤として極めて重要な役割を担いつつある現状を解説している。さらに、AnthropicがAtlassianを買収するという噂の背景にある戦略的な意味や、CRM、ERPなど他の企業向けツールが今後AIインフラとしてどう評価されるべきかについても考察している。
AIエージェントの基盤となる退屈なソフトウェア
2026年において最も驚くべきソフトウェアカテゴリーの一つについての話をします。私が話しているのは、今やAIエージェントの基盤となっているイシュートラッカーのことです。これらは決して最初からそのために作られたわけではありません。私たちが自分たち自身のために構築したプログラムが、偶然にもエージェントにとって非常に役立つものになったという、2026年で最も魅力的なストーリーの一つだと思います。
イシュートラッカーはAIのために設計されたわけではありませんし、今でもそうです。しかし、エージェントがどうしても必要とする要素、例えば状態管理、所有権、権限、履歴、あるいは次に何が起こるべきかという明確な概念をたまたまエンコードしていたために役立つようになったのです。イシュートラッカーは私の一番のお気に入りの例です。エンジニアリングのシステムにおいて、最も退屈なソフトウェアだからです。これがエキサイティングなものだなんてごまかすつもりはありません。これは人々がよく不満を漏らす対象です。Jiraなどがその代表ですね。プロセス上の負担のように感じられ、誰もがもっとシンプルで、軽く、目に見えないものにしたいと願っているものです。
それにもかかわらず、イシュートラッカーは今、世の中にあるエージェントインフラの中で最も重要なピースの一つに静かになりつつあります。なぜなら、エージェントに実際の仕事をさせたい場合、難しいのはモデルを賢くすることだけではないからです。本当に難しいのは、エージェントに仕事を見つける場所を与え、誰がその仕事の責任者なのかを理解させ、それがどのような状態にあるのかを把握させ、何が変更されたのかを確認させ、レビューを依頼し、結果を返すための場所を与えることなのです。
これらはまさに、イシュートラッカーが人間のために構築された目的そのものです。引き継ぎ、記憶、説明責任、依存関係、レビューのために作られました。そして偶然にも、これらはエージェントが必要とするものとほぼ完全に一致しています。
イシュートラッキングの死とSymphonyの登場
だからこそ、先月の小さな製品ニュースが、見かけ以上に大きな意味を持つのです。LinearのCEOは、イシュートラッキングは死んだという趣旨のメッセージを公開しました。そしてそれから1ヶ月余り後、OpenAIはSymphonyというオープンソースのコードオーケストレーション仕様を公開しました。その中心的なアイデアは、自律型コーディングエージェントのコントロールプレーンとしてイシュートラッカー、具体的にはLinearのボードを使用するというものです。
これがこの領域における最大の矛盾です。2026年において、人間がイシュートラッキングを行う体験そのものは死に絶えつつあるのかもしれません。しかし、基盤としてのイシュートラッキングは昇格しつつあります。人間が手作業で厄介な現実をチケットに変換するという古い習慣は、間違いなくプレッシャーにさらされています。ですが、イシュートラッカーの根底にある構造、つまり状態遷移モデル、担当者フィールド、監査証跡、依存関係グラフといったUIの裏側にあるものは、価値を下げるどころか、むしろその価値を高めているのです。
なぜイシュートラッカーがエージェントにうまく機能するのかを理解すれば、他の多くの場所でも同じパターンを見つけ始めることができます。CRM、サービスデスク、ERP、カレンダー、ソースコード管理、人事システム、財務システムなど、私たちがすでに作成したプログラムの多くは、見た目以上にエージェントにとって有用です。
ですからこの動画は、イシュートラッカーについての話ではありますが、同時にずっと大きな問いについての話でもあります。私たちが偶然作り上げてしまった退屈なツールのうち、エージェントが必要とするものは一体どれなのかという問いです。
ここから4つの要素に分けて解説していきたいと想います。1つ目は、なぜエージェントがイシュートラッカーのようなものを必要とするのか。2つ目は、人間の協調作業のために構築した退屈なインフラが、なぜエージェントの協調作業にこれほど見事に適合するのか。3つ目は、AtlassianやLinear、Salesforce、ServiceNowといった魅力に乏しい企業向けツール群が、なぜ突然、人々が考えていた以上に戦略的な優位性を手にしたのか。そして4つ目は、社内のどのツールがそのようなエージェントインフラになり、どのツールがラップされたり置き換えられたりするのかを見分ける方法です。
手短に言えば、2026年は退屈なツールが勝者となるということです。今本当に興味深い問題は、次にどの退屈なツールが勝つのか、そしてそれはなぜか、ということです。
イシュートラッカーが解決してきた課題
少しLinearのメッセージに話を戻しましょう。CEOのKariが主張したことは実際に非常に理にかなっていました。3月24日にLinearのCEOであるKariは、イシュートラッキングは死んだというページを公開しました。その基本的な考え方は、イシュートラッカーはソフトウェア開発の引き継ぎモデルのために構築されたものだという点にあります。
プロダクトマネージャーが仕事の範囲を決め、別の誰かがチケットを書き、さらに別の誰かが後でそれを引き受け、チケットは様々なステータスを行き来し、人々は優先順位や受け入れ基準、所有権、ロードマップ、依存関係、あるいはそれがバグなのか機能なのかについて議論する。そのような世界のために作られたのです。そして非常にゆっくりと、仕事の助けとなるはずだったシステム自体が、仕事の大きな部分を占めるようになってしまいます。
これはLinearが元々解決しようとしていた問題の核心を突いており、現実にある深刻な問題です。強調しておきたいのですが、私はLinearもJiraも両方使ったことがありますし、なぜ私たちがLinearに乗り換えたのかも理解しています。Linearは高速で直感的です。イシュートラッカーを使ってこの問題を解決しようとするなら、乗り換える理由もよくわかります。
しかし、個人的にLinearを使ったことがあるかどうかに関わらず、おそらく皆さんも何らかのチケッティングシステムを使ったことがあるでしょう。Jiraや大幅にカスタマイズされたプロジェクト管理システム内で働いたことがあれば、これがどのような感覚か正確にわかるはずです。チケットは結局、現実とチームの間の翻訳レイヤーになってしまうのです。
顧客が問題を抱えている。デザイナーがそれを解決するアイデアを持っている。エンジニアがバグを発見する。サポート担当者が同じクレームを5回聞く。このような整理されていないコンテキストのすべてが、どこかに行き着かなければなりません。それらはタイトル、説明、担当者、状態、そしておそらく期限という情報を持つ1つのレコードに圧縮されます。
この圧縮は便利ですが、同時にコストもかかります。そのためKariがエッセイを書いたとき、彼はエージェントがこの図式を変えると指摘しました。エージェントは根底にあるコンテキストをより多く読み取ることができます。生の顧客フィードバック、内部の議論、製品決定、コード、ドキュメントなどを見ることができます。人間の手による翻訳作業を最初に行う必要が必ずしもなくなるのです。
それに対するLinearの答えは、人間が手動でチケットを動かす場所から脱却し、コンテキストが実行へと変換される共有の製品システムになることでした。Linearのエージェントスキル、自動化、コードインテリジェンス、コードの差分確認、そして最終的にはLinearのネイティブなコンテキストを利用してコードを書きバグを修正するコーディングエージェントです。
この部分については、彼は正しいと私は思います。インターフェースは変化しています。チケットを取り巻く人間の儀式的な作業は減りつつあります。人間が週の半分を費やして厄介な現実をきちんとしたチケットに変換するような世界は、もはや私たちの最終形態ではありません。
エージェントのデータレイヤーへの進化
しかしその後、OpenAIがSymphonyを公開し、まったく逆の視点を同じくらい明確に示しました。Symphonyは、Linearのようなプロジェクト管理ボードを用意してタスクを読み込ませ、それぞれの課題に対して専用のワークスペースを作成し、エージェントを継続的に実行し、人間にはただその結果をレビューさせればよいと主張しています。
OpenAIによれば、このモデルを使用したことで、一部の内部チームではプルリクエストの成功率が500%も向上したとのことです。そしてOpenAIの仕様では、Symphonyの展開において実際にLinearを選択すべきトラッカーとして使用しています。Symphonyは、ポーリング、課題ごとのワークスペース、実行中および終了状態、再試行、可観測性、同時実行制限、そして引き継ぎ状態を定義しています。人間のレビューは引き継ぎ状態の一例です。
言い換えれば、Symphonyの世界においてイシュートラッカーは死にませんでした。むしろ昇格したのです。人間の協調作業のための単なるユーザーインターフェースであることをやめ、エージェントの協調作業のためのデータレイヤーになりました。
この違いは重要です。Kariが無くすべきだと語っていた人間による翻訳ステップは、無くなっても構いません。しかし、私たちがイシュートラッカーを必要としている根底の基盤は、同時に強化される可能性があるのです。人間が嫌っていた部分、つまりチケットの手動での整理や、厄介な現実の手動での翻訳は消え去るかもしれません。その一方で、エージェントが必要とする部分、つまり実際に時間をかけて物事を追跡する機能は不可欠なものになります。
それが見えてくると、人間が必要とするものとエージェントが必要とするものの違いがわかると、すべてが違って見え始めます。エージェントは状態を持つチケッティングシステムに対して機能する必要があるという核心的な洞察を得ると、イシュートラッキングというカテゴリーの歴史全体が違って見えてくるのです。
イシュートラッカーの歴史とエージェントへの適合
これが真実である理由は、1998年までさかのぼります。Bugzillaは最初の標準的なイシュートラッカーの一つでした。Terry WeissmanがMozillaのために書いたもので、Netscapeが使っていた内部の欠陥トラッカーを置き換えるためのものでした。最初はTCLで書かれ、後にバックエンドにMySQLを使ったPerlに移行しました。最初の公開デプロイは1998年の4月でした。
Bugzillaの重要な点は、意図的に用途を絞っていたことです。Bugzillaチームはソフトウェアの欠陥を追跡することに集中したいと明言していました。一般的なプロジェクト管理システムやサポートキュー、あるいは普遍的なビジネスプロセスエンジンを作ろうとしていたわけではありません。彼らはただ一つの問題を解決しようとしていました。多くの人が非同期でソフトウェアを構築しているとき、バグがそのままどこかへ消えてしまい、誰にも対処されないままになるのをどうやって防ぐか、ということです。
そして、その狭い問題設定が非常に強力な形を生み出しました。バグは誰か一人の頭の中ではない外部に、永続的な状態を持つようになりました。それは誰かの受信トレイにあるわけでも、廊下での立ち話の中にあるわけでもありません。データベース上のレコードになったのです。新規、担当者割り当て済み、解決済み、確認済み、またはクローズといった状態遷移モデルを持ちました。もちろん、ソフトウェアの状態としてこれまで発明された中で最も感情的に正直な、修正しないという悪名高いステータスもありました。
システムには所有権がありました。担当者フィールドにより、誰の番なのかが明確になりました。作成、コメント、割り当て、解決、再オープン、マーク、複製、他のバグのブロックなど、今日でも使われている動詞を定義しました。依存関係もありました。このバグはこのリリースをブロックする、この課題はあの課題に依存している、といった具合です。誰が、いつ、何を、何から何へ変更したのかという監査履歴もありました。
これらのどれ一つとしてAIのために設計されたものはありません。当時は関連するようなAIは存在しませんでした。これは単に、人間たちがタイムゾーンを越え、チームを越え、リリースサイクルを越え、そして記憶のギャップを越えて、ソフトウェアの作業を調整しようとした結果に過ぎません。
しかし、これらの人間に対する制約が、エージェントの制約と非常に近いことがわかってきたのです。人間はコンテキストを忘れます。同様に、エージェントもコンテキストを失います。人間は引き継ぎを必要とします。エージェントも引き継ぎを必要とします。人間には説明責任が必要です。そしてエージェントには可観測性が必要であることがわかりました。人間は権限を必要とします。エージェントはさらに厳密に権限を必要とします。人間は共有の信頼できる情報源を必要とします。作業が数日、数週間に及ぶ場合、コンテキストウィンドウは信頼できる情報源にはならないため、エージェントにもそれが必要になります。
そういう意図ではなかったという意味で、これは偶然です。もっとも、私たちがエージェントを設計した方法の多くは人間を模倣しているのだと主張することもできるので、思ったほど偶然ではないのかもしれません。エージェントが偶然人間に似て設計されたにせよ、意図的にそう設計されたにせよ、人間の弱点を補うために構築したシステムは、エージェントの弱点も非常にうまく補ってくれるのです。だからこそ、古いイシュートラッカーの形が生き残り続けているのです。
ユーザーエクスペリエンスがデータ品質を生む
カテゴリーの進化の過程にも同じパターンが見られます。BugzillaはMozillaから飛び出し、一世代のオープンソースプロジェクトのデフォルトのトラッカーになりました。その後2002年にJiraが登場し、同じ基本モデルを企業向けに持ち込みました。Jiraはワークフローやカスタムフィールド、プロジェクト階層、権限、統合機能を追加し、ほぼすべての企業の内部プロセスをツールにマッピングできるほどの高い設定性を備えていました。
それがJiraの商業的な天才性でした。あなたの会社そのものになれるのです。しかしそれは同時に、開発者がJiraを嫌う理由でもありました。すべてのJiraの導入環境が独自の迷宮と化しました。基礎となるプリミティブは良かったのですが、それを販売可能にするための設定の表面積があまりにも大きすぎたため、ツールが周囲の組織的な機能不全をすべて吸収してしまうことができたのです。
Linearはその後、異なる哲学を持って登場しました。Linearは、組織図やあらゆる奇妙な承認プロセスを持ってくれば、それをソフトウェアで愛情を込めて再現しますとは言いませんでした。Linearは、これがあなたの問題であり、私たちのモデルを使ってください、これはよりクリーンなモデルですと言ったのです。課題はサイクルの中に存在し、サイクルはプロジェクトに接続します。UIは高速で、意見は強力です。カスタマイズ可能な領域ははるかに小さくなっています。
だからこそLinearはJiraと比べてとても快適に感じられたのです。Linearが新しい基盤を発明したわけではありません。基本的なデータモデルは同じでした。課題、状態、担当者、優先順位、依存関係、履歴。Linearの革新は、そのモデルを人々が自発的かつ継続的に使いたくなるほど快適なものにしたことです。
そして直感に反するかもしれませんが、エージェントにとって重要なのはそこなのです。良いUXは人間の関与を増やし、それがよりクリーンなデータを生み出し、それがエージェントにとって有用になるからです。人々がツールを嫌うとき、彼らはツールを回避し、フィールドを空白にし、重要な決定をSlackで行い、偽のステータスを使い、作業が終わってからチケットを作成します。現実を反映しているからではなく、誰かに強制されたからトラッカーを使うのです。
人々がツールを気に入れば、実際の作業の多くがツール内やシステム内に残るようになります。それはつまり、状態がよりクリーンで、説明がより的確で、担当者が最新で、依存関係のでっち上げが少なくなることを意味します。監査履歴も実際に役立つものになります。LinearはUXの勝利でした。UXの勝利がデータの勝利になり、人々が良いUXを使ったからです。
エージェントが登場すると、このデータの勝利がはるかに大きな意味を持ちます。なぜなら、エージェントはプロジェクト管理ツールがエレガントに感じられるかどうかは気にしないからです。エージェントが気にするのは、内部の状態が行動を起こすのに十分なほど信頼できるかどうかです。これが第一の重要な教訓です。最高のエージェントの基盤は、最も多くのAI機能を備えたツールではないかもしれません。それは、チームが気に入っているために何年にもわたってクリーンに使ってきたツールかもしれないのです。そしてそうです、これは2026年における優れた人間向けのUXの重要性を訴えるものでもあります。私たちにはまだそれが必要なのです。
エージェントがイシュートラッカーの形状を求める理由
さて、なぜエージェントがこの特定の形状の製品をこれほど強く求めるのかについて話しましょう。エージェントループは永続的な状態を強く求めています。コンテキストウィンドウは数に入りません。要約されることも、ずれることも、切り捨てられることもあります。作業が複数の実行、複数のエージェント、複数日にまたがる場合、リセットされる可能性もあります。状態はモデルの外部のどこかに存在する必要があります。
チケットがその役割を果たします。エージェントは実行の開始時にチケットを読み、終了時に何が起こったかを書き戻すことができます。状態が以前の会話の中に閉じ込められていないため、次の実行で作業を引き継ぐことができます。これは非常に退屈に聞こえるかもしれませんが、決して退屈なことではないと約束します。デモと実際に機能するエージェントシステムとの間の最大の違いの一つなのです。
エージェントはまた、引き継ぎのセマンティクスを必要とします。今、誰がそれを担当しているのか。エージェントが作業すべきなのか。人間を待っているのか。別のタスクによってブロックされているのか。レビューの準備ができているのか。完了しているのか。優れたトラッカーでは、これらを記憶に頼ることはありません。雰囲気に頼ることもありません。これらはフィールドとして存在します。
担当者フィールドがその問題の一部に答えを出します。ステータスがその問題の一部に答えます。依存関係グラフがその問題の一部に答えます。そしてコメント履歴がその一部に答えます。これらのフィールドが組み合わさることで、プロトコルのようなものになります。それこそがSymphonyが活用しているものです。ボードは単なる視覚的な計画用のインターフェースではありません。ボードは状態遷移マシンなのです。エージェントが時間の経過とともに自分のステータスを追跡するための方法であり、それがエージェントにとって意味のある仕事を実際に成し遂げるために不可欠であることがわかっています。
エージェントシステムには、同時に多数のワーカーを調整する方法も必要です。ここで、Cursorの長時間稼働するエージェントに関する研究が役立ちます。Cursorは大規模なコーディングプロジェクトで何百ものエージェントを実行することについて執筆し、本格的になると単純な協調作業はすぐに破綻することを発見しました。
もしすべてのエージェントがボールに群がるようなフラットなエージェントシステムを持っていたら、エージェントはロックを長く保持しすぎます。解放するのを忘れます。お互いを待ちます。リスクを回避するようになり、簡単なものばかりを選びます。彼らが本来やるべき困難なエンドツーエンドの仕事の代わりに、小さなタスクばかりを引き受けます。
言い換えれば、エージェントのフラットな組織は調整の問題を抱えており、イシュートラッカーは調整ツールなのです。すでに作業の単位を持っています。すでに割り当て機能を持っています。すでにステータスを持っています。すでにブロッカーを持っています。すでに優先順位を持っています。20個のターミナルを開かなくても人間が何が起こっているかを確認できる方法をすでに持っています。そのため、エージェントシステムはゼロから調整レイヤーを発明する必要がありません。企業がすでに信頼しているものをそのまま使用できます。
次にエージェントが必要とするのは監査可能性です。ここは多くの企業向けAIが端っこから崩れ始める部分でもあります。デモは機能するでしょう。パイロット版も非常によくできているはずです。そして本番環境で何かがうまくいかなくなり、欠陥に関するごく基本的な質問に誰も答えられなくなります。エージェントは何を見たのか。何を決定したのか。何を変更したのか。誰がそれを承認したのか。作業の前後でどのような状態だったのか。
皮肉なことに、イシュートラッカーは何十年もの間この種の履歴を記録してきました。非同期で働く人間がタイムゾーンを越えて再生可能な履歴を必要としたためです。現在、まさにその同じ履歴がエージェントの作業を調査可能にしているのです。
最後になりましたが、エージェントには権限が必要です。自律型エージェントのセキュリティに関するストーリー全体は、スコープ化されたアクセスについてのものです。エージェントは何を読めるのか。何を書けるのか。どのシステムに触れられるのか。どのアクションに承認が必要なのか。どのアクションが完全にブロックされているのか。
企業のイシュートラッカーはすでに権限モデルの内部に存在しています。Jiraのプロジェクトには役割があります。Linearのワークスペースには権限があります。AtlassianのRovo MCPサーバーは、ユーザーの既存のアクセス制御を尊重します。これらのシステムはエージェントのために構築されたわけではありませんが、制御された作業のために構築されました。
そしてこれにより、シンプルなルールが生まれます。エージェントは、人間の担当者ができる以上のことを行う権限を与えられるべきではない、というルールです。そして、作業がすでにレコードと所有者とアクションと履歴を持つ権限システムの中に存在している場合、その役割を実装するのははるかに簡単になります。
AnthropicによるAtlassian買収の噂が意味するもの
これらをすべてまとめると、エージェントとチケッティングシステムの適合性は非常に明白になります。エージェントは永続的な状態を必要とします。明確な所有権を必要とします。合法的な遷移、制限された権限、監査履歴を必要とします。イシュートラッカーにはすでにそれらのものがあり、だからこそSymphonyの概念を見た後ではそれが非常に当たり前のように思えるのです。驚くべきことは、OpenAIがLinearをそのまま使ったことではありません。驚くべきなのは、私たちがエージェントレイヤーがワークトラッカーを通じて実行されるのではなく、ワークトラッカーを置き換えるだろうと期待していた時期があったことです。
このことは、Atlassianの見え方を全く違うものにします。過去10年間、多くの人々はJiraを古い世界のものとみなしてきました。強力で、定着していて、厄介で、設定可能すぎました。エンタープライズのプロセスに深く埋め込まれていました。しかし、イシュートラッカーがエージェントの基盤であるならば、Atlassianはエージェントが読み取り可能な作業状態の世界最大のインストールベースの一つを所有していることになります。そしてそれは物事の見方を大きく変えますよね。
2025年5月、AtlassianはリモートMCPサーバーのベータ版を発表しました。その狙いは非常にシンプルでした。AIツールがJiraやConfluenceのデータとやり取りできるようにすることで、Claudeを最初の公式パートナーとし、基盤となるインフラストラクチャにCloudflareを採用しました。2026年2月には、AtlassianはRovo MCPサーバーが一般提供されたと発表しました。幅広いクライアントをサポートしています。Jira、Confluence、Compassの検索と要約が可能です。課題やページの作成と更新ができます。OAuthを使用し、既存の権限を尊重します。管理者の制御とホワイトリスト機能をサポートしています。
これは単なる統合ではありません。これはAtlassianがJiraとConfluenceをエージェントが読み書きできるようにしているということです。仕組みとしては、SymphonyがLinearを前提としているのと同じパターンです。作業がすでに存在するシステムを採用し、制御されたインターフェースを通じてそれを公開し、エージェントがその作業グラフに対して動作できるようにするのです。
これが、AtlassianとAnthropicの関係が非常に興味深い理由です。AtlassianはリモートMCPの取り組みを立ち上げ、彼らが最初に選んだのがAnthropicでした。そして2月に、AnthropicはAtlassian Williams Racingと複数年のパートナーシップを結び、Claudeをチームの公式シンキングパートナーとし、Williamsの内部オペレーション全体にClaudeを統合しました。
しかし、そのF1の取引はここでの主要なストーリーではありません。スポンサーシップはあくまでスポンサーシップです。ブランドの方向性の一致の方がより多くを物語っています。企業のエージェントレイヤーになりたいと考えているAIラボが、JiraとConfluenceを所有する会社のすぐ近くに位置しているのです。
そしてここで噂が飛び交います。AnthropicがAtlassianをプレミアム価格で買収するかもしれないという噂がオンラインで出回りました。これは噂として扱ってください。情報ではありません。正式な発表も、SECへの提出書類も、契約もありません。そしてそれが実現するという確証もありません。
しかし、この噂が一つの理由から依然として興味深いものです。数年前なら、フロンティアAIラボがAtlassianを買収するなどという話は非常に奇妙に聞こえたでしょう。なぜモデルの会社がイシュートラッカーの会社を買うのか、と。しかし今では、特定の噂がどこにも行き着かなかったとしても、人々が真剣に受け止めるほどその論理は明白になっています。なぜなら、イシュートラッカーはもはや単なるチケッティング製品ではないからです。それは企業の内部でどのように仕事が行われているかを示す地図なのです。
Anthropicにとって、その情報を知ることは有益です。プロジェクトを知り、依存関係を知り、所有者を知り、履歴を知り、承認を知り、どの作業が重要でどの作業がブロックされているかを知っています。それこそまさにエージェントが必要とするコンテキストです。
つまり、本当のヘッドラインはAnthropicがAtlassianを買収するかもしれないということではありません。本当のヘッドラインは、エージェントの時代において、Jiraはインフラのように見えるということです。
他の退屈な企業向けツールへの展開
そして一度Jiraをそのように見ると、他の多くのソフトウェアもあなたの頭の中で再評価され始めます。ここが、ソフトウェアエンジニアリングやチケッティングシステムをはるかに超えて、より大きな戦略へと飛躍する部分です。なぜなら基盤仮説は現実だからです。
永続的なレコード、定義された動詞、所有権の権限、監査履歴を持つツールは、ほぼ偶然にソフトウェア全体でエージェントが使用可能になります。これらの特性を持たないツールは、エージェントが使えるようにするために非常に高価なラッパーを必要とします。そしてエージェントレイヤーは、基盤となる製品が決して持っていなかった構造を発明しなければなりません。
では、イシュートラッカーのようなツールとは何でしょうか。第一に、そして明らかなのはCRMです。SalesforceやHubSpotは収益のためのイシュートラッカーです。アカウント、連絡先、商談、所有者、ステージ、次のステップ、履歴、権限、そして統合機能を持っています。営業チームはすでにそこの状態遷移モデルの中で生活しています。取引は見込み客の発掘から資格確認、提案、交渉、そして成約または失注へと移動します。
これはエージェントの基盤です。エージェントはアカウントを調査し、フォローアップの草案を作成し、フィールドを更新し、リスクにフラグを立て、次の会議の準備をすることができます。外部に何かを送信する前に人間の承認を求めることもできます。CRMはすでに永続的な状態のレイヤーなのです。
二番目の明らかなカテゴリーは、サービスデスクソフトウェアです。Zendesk、ServiceNow、Intercom、Jira Service Management。これらは顧客問題のためのイシュートラッカーです。チケット、担当者、ステータス、SLA、エスカレーションパス、マクロ、顧客履歴、監査証跡、権限がすべて組み込まれています。カスタマーサポートエージェントをゼロから設計する場合、その大部分を再構築することになるでしょう。ですからエージェントはサービスデスクを置き換えるのではなく、それを通じて動作することになります。
三番目のカテゴリーはERPやビジネスプロセスシステムです。SAP、Oracle、Workday、NetSuite。これらは楽しいツールではありません。誰も承認ワークフローの中で一日を過ごすことにワクワクして朝起きることはありません。しかし、これらはレコードを持ち、ビジネスオブジェクトを持ち、権限を持ち、承認機能や監査証跡を持ち、お金や人、在庫、調達、給与、コンプライアンスがビジネス内をどのように移動するかをエンコードしています。それこそまさに、エージェントが実際の仕事をするために必要とする退屈な構造なのです。
そして、より規模は小さいものの、依然として重要なケースもあります。カレンダーは時間のためのイシュートラッカーです。イベント、参加者、所有者、部屋、空き状況、変更、履歴を持っています。ソースコード管理はコード変更のためのイシュートラッカーです。ブランチ、コミット、プルリクエスト、レビュアー、チェック、マージステータス、責任所在、履歴です。調達ツールは支出のためのイシュートラッカーです。人事情報システムは従業員と役割のためのイシュートラッカーです。財務システムはお金の動きのためのイシュートラッカーです。
このパターンは繰り返されます。システムが、本当に重要な仕事の周りで非同期に人々を調整するために構築されたものであれば、それはおそらくエージェント基盤の骨組みを持っています。
この話の中で弱い候補となるものも同じくらい重要です。メールには状態があります。履歴があり、権限があります。しかし、動詞が非常に弱いのです。返信、転送、アーカイブ、ラベル付け。一般的なメールモデルには、それを割り当てたり、解決したり、ブロックしたり、承認したりするネイティブな方法がありません。これは、エージェントがメールの処理を手伝うことはできても、メール自体は非常にクリーンなコントロールプレーンにはならないことを意味します。会話的すぎるのです。
SlackやTeamsも同様です。これらには膨大な量のコンテキストが含まれていますが、構造は主にトランスクリプト（記録）の構造です。スレッドはメッセージの山にすぎません。仕事の状態はエンコードされているというより、暗示されていることが多いです。エージェントは間違いなくSlackを読むでしょう。Slackを要約するでしょう。彼らは今やSlackの中にいます。Slackからタスクを抽出するでしょうし、エージェントがSlackに組み込まれることで、Slackは人間がいる場所であるというメリットを享受してきました。しかし、仕事の状態が存在する唯一の場所がSlackである場合、エージェントはあまりにも多くのことを推論しなければなりません。
ドキュメントツールは、このフレームワークの中間あたりに位置します。Confluence、Notion、Google Docs。これらには権限があります。バージョン履歴があります。コメントがあります。データベースを持つこともありますが、所有権は非常に曖昧であることが多く、動詞は通常、編集、コメント、共有です。これらは有用なコンテキストですが、本格的な仕事の基盤としては弱いです。
スプレッドシートは、最も奇妙な中道のケースです。行があり、列があり、数式と構造がありますが、スキーマはユーザー定義であり、暗黙的であることが多いです。人間がうまく設計していればスプレッドシートは信じられないほど構造化されたものになりますが、人間が個人のメモ帳のように設計していれば完全に不可能なものにもなります。そのため、スプレッドシートエージェントは今後良くなっていくでしょうが、スプレッドシートは簡単なケースではありません。エージェントは行動を起こす前にユーザーのスキーマを推論しなければならないからです。
これらすべてが、皆さんのスタックにあるあらゆるツールに対する非常にシンプルな診断基準を与えてくれます。ただ5つの質問をするだけです。このツールにはレコードがあるか、それともほとんどコンテンツだけか。状態遷移モデルがあるか、それとも単なるラベルか。所有権は明示的なフィールドか、それとも会話から推測するものか。動詞は構造的か、それとも単なる会話的か。これについては両方の例を挙げました。履歴はクエリ可能か、それとも単に見えるだけか。
これらの質問で良いスコアを出すツールは、エージェントのインフラになります。スコアが低いツールは、良くてコンテキストのソースにしかならず、多くの場合、誰か別の人がその周りに本物の基盤を構築する場所になります。
これはソフトウェアの全く異なる評価方法です。つまり最も重要な質問は、この製品にAIチャットボットがあるかどうかではありません。より良い質問は、エージェントが製品内の作業状態を安全に理解し、変更できるかどうかです。これらは同じ質問ではありませんよね。最も重要な質問は、この製品にAIチャットボットがあるかどうかではありません。最も重要な質問は、エージェントがこの特定の製品内の作業状態を安全に理解し、変更できるかどうかです。全く異なる質問です。
開発者、チーム、そしてリーダーへの影響
では、開発者にとってこれはどういう意味を持つのでしょうか。その意味合いは非常にシンプルだと思います。あなたのデータモデルが戦略的な表面になるということです。今後エージェントに使ってもらいたい製品を開発しているのなら、UIにチャットを後付けすることから始めないでください。それは非常に2024年的なアプローチです。
基盤となる状態をクリーンにすることから始めてください。レコードを公開してください。動詞を定義してください。所有権を本当に明示的にしてください。履歴を保存してください。モデルに権限を組み込んでください。本当に重要なアクションは、本物のAPIやMCPサーバーを通じて利用できるようにしてください。
あなたの製品が不透明であれば、エージェントはUIをスクレイピングするか、ユーザーの意図を推測しなければならず、それは非常に壊れやすいものになります。あなたの製品が非常にクリーンな状態とクリーンな動詞を公開していれば、エージェントはそれを通じて操作することができます。そしてそれが、ボードにAIを追加しましたというレベルと、実際にエージェントスタックの一部になり誰も私たちを脅かすことはできないというレベルの違いです。単にデモのためにAIを追加したことと、実際にエージェントスタックの一部になったことの違いなのです。
チームにとって、その意味合いはより居心地の悪いものになります。あなたの作業追跡ツールの選択が、エージェントインフラの選択になりつつあるからです。そしてあなたはそのことに慣れなければなりません。JiraかLinearかという決断は、かつてはUXとワークフローの決断のように感じられました。エンジニアはどのツールが好きか。私たちの計画プロセスに合うのはどれか。GitHubと統合できるのはどれか。人々を苛立たせないのはどれか。
それらの質問は今でも重要です。しかし今、もう一つの質問があります。エージェントをどの基盤で実行させたいかということです。作業データがクリーンであれば、エージェントは有利なスタートを切れます。作業データがSlackのスレッドや、半分しか埋まっていないチケット、謎のスプレッドシート、文書化されていない部族的な知識の中に散らばっている場合、エージェントはまさにあなたが助けてほしい場所で苦労することになります。
これは、整理されていないオペレーションの隠れたコストの一つです。整理されていないオペレーションは、かつては人間に対する税金のようなものでした。人々は会議や記憶、人間関係、あるいは英雄的な努力でそれを補うことができました。エージェントはそれらのことが人間より苦手です。エージェントはビジネスが読み取り可能であることを本当に必要としています。
つまり、ワークフローを整理し、システムを統合し、フィールドを強制し、所有権を最新に保ち、ステータスが実際に意味を持つようにするという退屈な部分は、単なる良い衛生状態というだけでなく、AIへの準備状況そのものなのです。
リーダーにとって、その意味合いは非常に戦略的です。あなたの会社がすでに稼働させているその退屈なインフラ、チケットやレコード、ワークフロー、承認、コメント、履歴、権限、依存関係グラフは、再評価されています。これらは単にあなたのチームがたまたま作り出しているものではありません。これらはエージェントがあなたのビジネスの基盤を構築するために使用する地図なのです。
これは間違いなく既存企業に有利に働きます。AtlassianやSalesforce、ServiceNow、Microsoft、Oracle、SAP、Workdayのような企業です。これらの企業は記録のシステムを所有しています。彼らは最も派手なデモを持っていないかもしれません。未来のようには感じられないかもしれませんが、彼らはエージェントがその上に構築する基盤を所有しています。そしてその基盤を置き換えるのは困難です。
だからこそ私は、全く新しいエージェントプラットフォームのストーリーの多くに少し懐疑的なのです。エージェントプラットフォームがレコード、権限、履歴、ワークフロー、あるいはユーザーの習慣を所有していないなら、どこかからそれらを借りてこなければなりません。既存のシステムから借りなければならないのです。それはラッパーになります。ラッパーは価値を持つことがあります。いくつかのラッパーは非常に大きな会社になりますが、誰か別の基盤の上に乗るものになるよりも、基盤自体を所有する方が優れています。
それがイシュートラッカーから得られる戦略的な教訓です。人間の協調作業のためのインフラの30年間の蓄積は、エージェントが到着したからといって消え去るわけではありません。それはエージェントが消費する表面になるのです。その周りにラッパーを構築する企業もいるでしょう。それを公開することを選ぶ企業もいるでしょう。それを所有し、意図的にその上でシステムを推進する方法を見つけ出す企業もいるでしょう。あなたは自分がその境界線のどちら側に立つことになるのかを知りたいはずです。
退屈なツールが勝者となる未来
物語の始まりに戻りましょう。Kariはイシュートラッキングは死んだと言いました。OpenAIはイシュートラッカーを自律型コーディングエージェントのコントロールペインとして使用するシステムを公開しました。基盤のストーリーを理解していれば、これは矛盾ではありません。古いユーザーエクスペリエンスは死につつあります。Kariは正しかったのです。人間があらゆるコンテキストを手作業で翻訳するという儀式は消え去ろうとしています。その世界は縮小しています。
しかし、その根底にある基盤は死んでいません。エージェントが機能するために必要な基盤は、永続的な状態です。エージェントが仕事をするためには、所有権、権限、状態遷移モデル、そして履歴といった基盤が必要なのです。では、私たちがすでに良いデータを入れているイシュートラッカーをなぜ捨てる必要があるのでしょうか。
そこが、私たちが仕事の共有マップを開発する場所になります。そして人間よりもエージェントの方が、その地図を必要としているのです。だからこそイシュートラッカーが勝利したのです。しかも最も退屈な方法で勝利しました。置き換えるには便利すぎる存在になったのです。誰もがそれを愛していたからではありません（Linearにはファンがいますが）、AIのために作られたからでもありません。人間とエージェントの協調作業をエンコードしていたから勝ったのです。人間の調整という困難な部分と、エージェントの調整という困難な部分には、私たちの多くが予想していた以上に多くの重なりがあることがわかりました。
次に非常に退屈な企業向けツールを見るときは、画面の隅にAIアシスタントがあるかどうかを尋ねないでください。レコード、状態、所有者、動詞、権限、履歴があるかどうかを尋ねてください。そして、彼らがそれを公開する意思があるかどうかを尋ねてください。もしそうであれば、そのツールはおそらく見た目以上に重要です。もしそうでなければ、誰かがその周りにエージェント基盤を構築するでしょう。
そして、その基盤の上に構築することと、その基盤を所有すること、あるいはそれが存在しないふりをしたり、横に放り出してもう必要ないと言ったりすることの違いは、非常に大きな意味を持つことになります。確かにKariが書いた人間の翻訳ステップは死につつありますが、時間の経過とともに物事を記録し続ける必要性は、エージェントも同様に抱える永続的なニーズなのです。
退屈なツールが勝ちます。そして今の仕事は、次にどの退屈なツールが勝つのかを見極め、これらの退屈なツールをどのようにつなぎ合わせてビジネスにとって有用なエージェント基盤を形成するかを考えることです。なぜなら、すべてのビジネスはこれらのエージェント基盤の独自のパッチワークを持っているからです。
ビジネスの中心にある優れたエージェントパイプラインの仕事の多くは、自社のエージェント基盤をマッピングし、ERPとCRMをどのようにつなぎ合わせるか、チケットシステムとどのようにつなぎ合わせるか、顧客の声とどのようにつなぎ合わせるかを考えることです。そこが正念場です。だからこそ、私たちはこれらのシステムにある現在のデータを真剣に受け止める必要があります。すべてを消し去って新しくクリーンな状態に設定するだけでは、本当の仕事はできないからです。
代わりに、自分が今いる現在のシステムをどのように監査し、これらの異なる記録システム間のデータベーススキーマを横断してどのように計画を立て始め、実際のライブコネクタに基づいてこのデータを真剣に扱うエージェントパイプラインをどのようにインストールできるかを見つけ出す、という立場にいる必要があります。もしもっと詳しく知りたい場合は、Substackに完全なガイドをまとめてあります。
「いやあ、退屈なツールは退屈だな」と思っている方もいるでしょう。すぐにもっとエキサイティングなハイパースケーラーの話題に戻ることをお約束します。チャンネル登録をお願いします。また次回お会いしましょう。
コメント