最近、あるSharePoint MVPの投稿を見ました。素直な高揚感です。MarkdownのサポートがSharePointに導入されたんです。冗談じゃありません。領域を内側から隅々まで知り尽くしている人の、ちゃんと裏付けられた本物の熱意です。
そして、わかります。SharePointの世界では、それはまさに実質的な進歩です。本物のユーザーが本物の課題を解決するうえで意味があります。MVPになるには、専門知識と、社会的な評価が必要です。彼が祝うのは正しいことでした。
私が引っかかったのは、彼の投稿ではありませんでした。私自身との対比でした。つまり、昔私がワクワクしていたことと、今私が取り組んでいることの違いです。
私が書いていたはずの投稿
18か月前なら、私はまさにその投稿を書いていたでしょう。同じ熱意。同じ、ちゃんと積み上げた専門性。同じく、これが意味のある進歩だと本気で信じていたはずです。そして、当時の私がいる世界では、私は正しかった。
でも私は、この1年をかけて、別のやり方で働くことに踏み込んできました。そして長い週末のある日、エージェントが自律的に働くためのインフラを構築しました――エージェントループ、エラー回復、品質ゲート。自律コードを恐ろしいものではなく信頼できるものにするための、あまり華のない土台です。日曜の夜までに、これらのエージェントは111個のSharePoint Webパーツと5つのバックエンドサービスを足場（スキャフォールド）として作り上げていました。設計、構築、テスト。すべてローカルで。コードに人の手は一切入りません。
3日間のツール作りで、数か月分の人間の成果が生まれました。とはいえ、その出力がすごいところではありません。学習曲線のほうが、急峻だったんです。
SharePoint MVPは間違っていませんでした。彼がしていた会話が、ただ別のものだっただけです。そして、その部分が私を怖がらせました。
YouTubeでは教えてくれないこと
ここから先、どんなチュートリアルでも、TikTokでも、カンファレンストークでも用意してくれないのは――“地道な苦労”です。
その3日間、何かがだいたい数時間ごとに壊れていました。比喩ではなく、文字通りです。エージェントがファイルを読めるように、macOSの権限を直す。すると今度はゲートウェイの再起動が必要になります。再起動すると、モデル設定が壊れていることが判明します――空のモデル名で、理由を追っている間、2時間何も動きません。それを直したと思ったら、今度はビルドが失敗します。SCSS設定が違うツールチェーンを拡張しているからです。Gulp用に書かれていて、Heftではありません。書き直すと、Yeomanの足場生成器がCLIフラグを黙って無視します。前回の実行で残った.yo-rc.jsonが存在するからです。それを回避するための手動テンプレートスクリプトを作ります。するとディレクトリ名がPascalCaseになってしまい、パイプラインはkebab-caseを期待していた。直す。今度はNode 22でC++ネイティブモジュールがコンパイルできません。しかも、これはまだエージェントがループする件に到達していません――ループ検知を強固にするまで、同じ3つの壊れたコマンドを繰り返すことになります。
こうしたことは、どのチュートリアルにも載っていません。動画で見ても追体験はできません。あなたが生身で経験しないといけないんです――手を動かして、夜遅くまで粘って、近道はない。
メモリファイルは何度もパッチされました。モデルの好みも何度も変わりました。同期方式が、PiサーバーからGitベースの回復へと移りました。設定は丸ごと書き換えられました――config.json、sass.json、tsconfig、ESLintルール、パイプラインスクリプト全体。直したはずのところから、次の壊れ方が見えてきます。痛みのポイントは移動しただけです――同じ問題が、別のファイルで、さらに新しく創造的な方法で失敗する。
エージェント用インフラを作る、気取らない現実はこうです。あなたがやっているのは機能の開発ではありません。レジリエンス（回復力／頑健性）の設計です。自律的にWebパーツを組み立てる前に、その環境に耐えられなければならない。信頼できるようになる前に、考えられるあらゆる形で壊れてみせなければならない。“プロンプトエンジニアリング”で逃げ切れるものはありません。これはシステムエンジニアリングで、それは汚いものです。
同じ業界、同じところで起きている、2つの会話
私が何度も立ち返ってしまうのは、この2つです――Markdownのサポートを祝うこと、そしてエージェントがアプリケーション全体を自律的に作っていくのを見ること。これらは同じ業界で、同じプラットフォームで、同じ職種の人たちの間で起きています。
これは誰かへの批判ではありません。地面がどれほど速く動いているかを示すデータポイントにすぎません。
ギャップは、頭の良い人と遅い人の間ではありません。ソフトウェア開発が何に向かっていくのかについての、まったく異なる2つのモデルの間です。一方では、私たちはすでに知っているツールを、段階的に改善しています。もう一方では、ツールそのものが自分で使い方を学ぶようになっている。
そして、あなたが本物の専門家――何年にもわたる深いドメイン知識、公開された評価、実際の達成――を持っているとしても、それでもなお、第二の部屋が数軒先にできたのに、第一の部屋に立ってしまっていることは起こり得ます。
私は、ほとんどそうなりかけました。
ほとんど見逃した方法
先読みできていたから、この話をしているわけではありません。私は見ていませんでした。踏み込みの結果、そうなっていました。
私はSharePoint開発者でした。機械学習エンジニアではありません。AI研究者でもありません。求められたからです――SPFx、SharePoint Frameworkの“癖”を何年もかけて学んできた開発者でした。
変わったのは、私の知性や先見性ではありません。単純な問いでした。「AIにプロンプトを出し続けるのをやめて、AIのためのワークフローを設計するようにしたらどうなる？」
この転換――AIを“賢いオートコンプリート”として扱うのではなく、役割が定義され、品質ゲートがあり、監査証跡があるチームメンバーとして扱うようにする――が、私が歩いて入っていった扉です。自分が賢かったからではありません。好奇心があって、少し怠け者だったからです。そして代替案は、Webパーツ番号112を手で書くことだったので。
生まれてきたメソッド――今はWorks With Agentsと呼んでいますが、名前は重要ではありません――は難しくありません。単に、…違うんです。その違いは、認識のギャップを生みます。認識のギャップこそが、本当のチャンスが生まれる場所です。
これが意味すること（私たち全員にとって）
ここが不快な部分です。このギャップは埋まっていません。広がっています。
ツールは、メンタルモデルの更新よりも速く進化しています。平均的なチームリードが「今日のClaudeやCopilotで何ができるのか」を内面化するころには、エージェントはすでに別の何かへ移っているでしょう。私たちは技術導入のカーブの上にいますわけではありません。これは“分断化（フラグメンテーション）のイベント”です。
2026年5月時点で、私が真だと思うことは3つあります。
1. あなたの技術的な“堀（もとい、参入障壁）”は思っているより薄い。 もし競争優位が「機能をより速く作れる」だとしたら、研究ループ――cronジョブ、Web検索、LLMの分析、エージェントによる足場生成――で、特徴のセットが週末にクローンされ得ます。参入障壁はコンプライアンス、信頼、ドメインとの関係へと移っています。何か月、何年もかかるもの――時間が数時間で済むものではありません。
2. ボトルネックはコード生成ではない。検証（verification）だ。 エージェントが数秒で千行のコードを出せるなら、難しい問題は「コンパイルできるか？」ではありません。「本当に自分が必要としていることを、安全に、そして監査人に説明して証明できるのか？」です。規制産業ほどこの感覚が強く出ますが、これは全員にやってきます。
3. 「後れている」人たちは、バカじゃありません。別の部屋にいるだけです。 そして、私たちのほとんどは、まだ知らない部屋にいます。「am I ahead?（私は先を行っているか？）」が問いではありません。「今、私はどの部屋にいて、それがすでに外から見るとMarkdownのサポートのように見えているのか？」が問いです。
本当の問い
私は、きれいにまとまった結論を持っていません。SharePoint MVPが興奮していたのは正しいことでした。SharePointでのMarkdownは進歩です。でも、彼の投稿と私の画面の間のどこかで、進歩の測り方が根本的に変わったことに気づきました。ゆっくりとではありません。突然。そして、誰もが気づいたわけではありません。
そこで私がずっと考えている問いがあります。今、私はどの部屋にいて、完全に時代の最先端にいるように感じているのに、外から見るとすでにMarkdownのサポートに見えるのはどこなのか？
答えがあるなら――あるいは、これであなたが居心地悪くなったなら――本当にそれを聞いてみたいです。
