１．そもそもAIエージェントとは何なのか

私は、AIエージェントを難しく考えず、

と考えると分かりやすいと思っています。

これまでChatGPTを使うときは、 プロンプトで相談することが中心でした。

「これについて調べて」

「どうすればいい？」

「文章を書いて」

「SharePointではどう設定すればいい？」

AIが答えてくれる。

しかし、その答えを読んで、 実際にSharePointを開いて操作するのは自分です。

つまりAIは非常に優秀な相談相手でしたが、 仕事は最後に人間へ戻ってきました。

AIエージェントでは、 この関係が少し変わります。

たとえば、

「この会員が使うフォルダを準備しておいて」

と頼む。

するとAIが、自分の代わりにシステムへ働きかけ、 実際に仕事を進めます。

私はこの、

が、AIエージェントを理解する一番分かりやすい入口だと思っています。

２．GPTが登場したとき、「AIのApp Store」が始まるように見えた

ここで少し時間を戻します。

OpenAIがGPTsを発表したのは、2023年11月でした。

特定の目的に合わせたChatGPTを、 専門的なプログラミングをしなくても作れる。

それを他の人と共有できる。

さらにActionsを使えば、 外部のAPIにつなぎ、 データを取得したり、 外部システムを動かしたりすることもできる。

そして、それらのGPTを探して使える 「GPT Store」も発表されました。

2024年1月にGPT Storeが公開されたときには、 OpenAIによれば、すでに300万を超えるカスタムGPTが作られていました。

当時は、

という期待が大きく広がりました。

スマートフォンにアプリを追加するように、 ChatGPTの中にさまざまな専門GPTが並ぶ。

旅行のGPT。

会計のGPT。

教育のGPT。

会社独自のGPT。

そして必要なら、 それぞれが外部サービスのAPIにつながる。

考え方としては、

方向です。

今回つくったDSC Builder GPTも、 まさにこの考え方の延長にあります。

３．DSC Builder GPT――「できる仕事」を先に定義する

DSC Builderでは、 GPTからSharePointを自由に操作できるようにはしていません。

たとえば、

と頼む。

GPTは専用APIへ依頼します。

API側では、

• どのSharePointサイトを操作できるか
• どのフォルダを作れるか
• どんな会員番号を受け付けるか
• どんな権限を設定できるか

を、あらかじめ決めています。

つまりGPTに「何でもできる道具」を渡すのではなく、 必要な仕事だけを実行できる道具を用意する考え方です。

DSC Builderでは、さらに、

という流れをつくりました。

まず何を変更するか計画を出す。

私が確認する。

それから実行する。

最後に本物のSharePointから状態を読み直し、 予定と実際が一致したらPASSにする。

ここでは、 AIの自由度を意図的に小さくしています。

そんな方法です。

４．Claude in Chrome――AIが既存のサービスへ出かけていく

Claude in Chromeは、 これとはほとんど逆の発想です。

こちらでは、 SharePoint専用APIを私が用意する必要はありません。

自分でSharePointの管理画面へログインする。

その状態で、

「この設定を確認して」

「ここを変更して」

と頼む。

するとClaudeが、 人間と同じように画面を見ながら進みます。

つまりGPT型が、

仕組みだとすれば、 Claude in Chromeは、

仕組みです。

この違いは、 かなり大きいと思います。

APIが用意されていない社内ツールや、 古いシステムや管理画面でも、 ブラウザで操作できるのであれば、 AIが人間と同じ画面を使える可能性があります。

言い換えるなら、

発想です。

５．二つを比較すると、こうなる

この表をつくってみると、 単なる「便利さ」の違いではないことが分かります。

のです。

６．Claude in Chromeを先に使ったから、DSC Builderをつくろうと思った

実際の順番としては、 私はDSC Builderより先にClaude in Chromeを試しました。

最初に動かしたときは、 かなり驚きました。

SharePointの管理画面をClaude自身が開き、 設定を探し、 クリックしていく。

私はほとんど見ているだけです。

「これなら、わざわざ専用のアプリをつくらなくてもいいのではないか」

とも思いました。

何しろ、準備が簡単です。

私がSharePointへログインできればいい。

細かな画面操作を全部覚えていなくても、 Claudeが探してくれます。

これは非常に大きなメリットです。

一方、しばらく見ていると、 少し違う面も見えてきました。

人間がブラウザを操作するのと同じなので、 ときどき少しモタモタします。

セキュリティ確認のポップアップが出れば、 そこで止まることもありました。

さらに初期には、 権限グループを誤って削除してしまったこともありました。

それ以降、

• 今回は確認だけ
• まだ変更しない
• 実行前に確認する

と指示を明確にするようになりました。

この体験から、

と思ったのが、 DSC Builderをつくる一つのきっかけでした。

７．自由度と安全性は、どうしても表裏一体になる

ブラウザ型の最大の魅力は自由度です。

しかし、その自由度は、 そのまま注意すべき点にもなります。

Claude in Chromeは、 ログインしているWebページを直接操作できます。

そのため、ブラウザ型AIでは、 Webページやメールなどの中に埋め込まれた指示をAIが誤って受け取る 「プロンプトインジェクション」のようなリスクも考える必要があります。

Anthropicは、安全分類器や権限制御などの対策を用意していますが、 ブラウザを直接操作する以上、 自由度と安全性のバランスは重要になります。

現在のClaude in Chromeには、 3種類の権限モードが用意されています。

つまりブラウザ型のAIでも、

考え方になっています。

一方、DSC Builderでは、 安全装置の考え方が少し違います。

別のSharePointサイトは操作できない。

任意のURLは受け付けない。

できる操作も決まっている。

つまり、

という違いがあります。

８．「GPTがプラットフォームになる」という未来と、別の未来

ここが今回、 一番面白いと思ったところです。

GPTが登場した2023年には、

ような未来が見えました。

GPT Storeがあり、 専門GPTが並び、 それぞれが外部APIへ接続する。

ユーザーはまずChatGPTへ来て、 そこから必要なサービスを使う。

これは、

です。

しかしClaude in Chromeを使ってみると、 まったく別の未来も見えます。

今あるWebサイトや業務システムは、 そのままでいい。

SharePointも、そのまま。

管理画面も、そのまま。

人間向けにつくられた画面を、 AIも操作できるようになればいい。

つまり、

という未来です。

これはかなり発想が違います。

私は、今回実際に両方を触ったことで、 この違いがとてもはっきり見えました。

９．では、どちらが向いているのか

ここまで比較すると、

「では、結局どちらが正しいのか」

という話になります。

しかし私は、 今のところどちらか一方になるとは思っていません。

むしろ仕事によって分かれるのではないかと思います。

API型が向いている仕事

• 毎日、毎週、毎月、同じ処理をする
• 権限や個人情報を扱う
• 失敗したときの影響が大きい
• 実行履歴を残したい
• 同じ結果を安定して繰り返したい

ブラウザ型が向いている仕事

• 一度しかやらないかもしれない
• どの画面へ行くか事前に分からない
• APIが提供されていない
• 古い管理画面を使わなければならない
• いろいろなWebサービスを横断したい

今の段階では、

という使い分けが、 かなり自然に思えます。

そして将来、 この二つが近づいていく可能性もあります。

最初はブラウザ型AIに自由に仕事をしてもらう。

よく使う仕事が見えてきたら、 それを専用のAPIやワークフローへ落とし込む。

あるいは逆に、 専用APIでは対応できない例外だけをブラウザ型へ渡す。

そんな組み合わせも考えられます。

１０．Microsoftの仕組みを一通り使ってみて分かったこと

DSC Builderをつくるために、 今回はMicrosoftのさまざまなサービスを実際に使いました。

• SharePoint
• Microsoft Entra ID
• Azure Functions
• Azure Key Vault
• 証明書
• API
• OpenAPI

以前から名前は知っていたものもあります。

でも、自分で組み合わせて本当に動かしてみると、 理解の仕方がまったく違います。

「ああ、Entra IDというのは、 AIにこういう身分証を持たせるためにも使えるのか」

「Key Vaultは、 この秘密をここに置くためにあるのか」

「APIというのは、 単にシステム同士をつなぐだけではなく、 AIが安全に仕事をするための“道”にもなるのか」

それまで単なる製品名だったものが、 一つの仕組みとしてつながりました。

もちろん、かなり面倒でした。

動かない。

直す。

また試す。

今度は別のところで止まる。

それでも、 自分がChatGPTへ、

と頼む。

すると、自分でつくった仕組みを通って、 本当にSharePointが動く。

これは、やはり面白い体験でした。

１１．「AIが何をできるか」より、「どう仕事を渡すか」

今回、Claude in ChromeとDSC Builder GPTを比べてみて、 AIエージェントについての見方が少し変わりました。

重要なのは、

「AIはどこまで賢くなるのか」

だけではないのだと思います。

むしろ、

そこが、これから大きなテーマになりそうです。

自由に画面を動かしてもらうのか。

専用のAPIを用意するのか。

どこまで任せるのか。

どこで人間が確認するのか。

手綱を人間が握るのか。

それとも、 手綱そのものをシステムの中へ組み込むのか。

2023年にGPT Storeが発表されたとき、 私は「AIの中にさまざまなアプリが集まる未来」を想像しました。

そして今回Claude in Chromeを使ってみて、

という、もう一つの未来があることに気づきました。

どちらが主流になるのか。

それとも、 この二つが混ざっていくのか。

今の段階では、 まだ分かりません。

ただ、実際に作ったり使ったりしてみると、

そんなことを感じています。

１．第２章へ踏み出したところで、驚いた

前回の記事では、 Digital Supporters Clubの会員サイトをPower Pagesでつくろうとして、 AIと一緒に要求仕様や設計を考えていったことを書きました。

最初は、もっと簡単につくれると思っていました。

ところがAIと対話を続けるうちに、

「この場合はどうしますか」

「途中で失敗したらどうしますか」

「他の会員から本当に見えませんか」

と、一つ決めるたびに次の問いが出てきました。

その結果、要件定義からデータ設計、画面、権限、運用、 そして１２３件のテストケースまでつながっていきました。

そして最後に、

Power Pagesへの挑戦が第１章。

次はSharePointを中心に、まずはもっと小さく動くものをつくる。

そう書きました。

今回の出来事は、 その第２章へ踏み出した、とっかかりでの体験です。

SharePoint版をつくり始め、 その運営を少しでも楽にするための小さなツールを AIと一緒につくろうとしました。

その過程で、私は初めて、

しかも、それだけではありませんでした。

AIはユニットテストまでつくり、 実際にそのテストまで実行したのです。

これには、本当に驚きました。

２．残っていた、地味だけれど気の抜けない作業

SharePointとTeamsを使った小さな会員サイトをつくり始めると、 サイトの骨組みは少しずつ形になっていきました。

自分だけが見られる原稿の場所。

クラブの仲間に公開する作品の場所。

作品について感想を届ける場所。

Power Pages版で考えた、

「保存することと、公開することは違う」

「本人の非公開原稿は、他の会員から見えてはいけない」

という考え方も、そのまま引き継ぎました。

ところが実際に運営することを考えると、 一つ地味な作業が残りました。

作業そのものは、それほど複雑ではありません。

でも、間違えてはいけません。

本人だけが読めるはずの原稿が、 別の会員から見えてしまったら大きな問題です。

公開作品についても、 他の会員は読むことはできても、 編集できてはいけません。

会員が増えるたびに、同じ設定を行い、 最後に間違いがないか確認する。

地味ですが、かなり神経を使います。

そこで、この作業を支援する小さな管理ツールをつくることにしました。

名前は、

です。

たとえば、

とGPTに伝える。

すると、

ところまで支援する。

そんな道具を目指しました。

３．最初は、大きくつくりすぎた

ところが、最初に考えたDSC Builderは、 かなり大きなものでした。

新規会員の準備だけではありません。

• 長期間利用していない会員を見つける
• 利用継続を確認する
• 退会時にはアクセスを停止する
• 一定期間データを保持する
• 最後にはデータを削除する

入会から退会まで、 かなり広い範囲を自動化しようとしていました。

設計をレビューしていく中で、

「今の段階で、そこまでつくる必要があるだろうか」

という問いが出てきました。

以前、Power Platformのライセンス費用で立ち止まったときと、 よく似ています。

技術的につくれるか。

それだけではありません。

そこで範囲を大きく縮めました。

まず試すのは、 新しい会員１人を迎えるときのSharePoint設定だけ。

休眠管理も、退会処理も、削除の自動化も、 いったん将来へ送る。

そして設計に、

という考え方を入れました。

実際に試す。

本当に楽になるなら続ける。

効果が小さければ、そこで止める。

前回は、仕様書をつくることで、

「このシステムを本当につくるべきか」

を考えることができました。

今回は、AI自身を使った開発にも、 同じ考え方を適用することになりました。

４．本当にコードができた

設計を何度も見直したあと、 AIに実際のコードを書いてもらいました。

ここは、はっきり書いておきたいと思います。

私はプログラムを一行も書いていません。

私が行ったのは、

• 何をつくりたいのか
• どこまでつくるのか
• どんな場合には処理を止めるのか
• どんな結果なら成功なのか

そうしたことをAIとの対話で考えることでした。

設計が決まると、AIがコードを書きました。

それまでも、

「AIはコードを書ける」

という話は知っていました。

だから、ここまではある程度想像できました。

でも、本当に驚いたのは、その先でした。

５．AIが、ユニットテストまで実行した

AIは、コードを書いて終わりではありませんでした。

そのコードが正しく動くかを確かめるための ユニットテストも用意しました。

そして、

そこまでが、 ひと続きの開発作業として進んでいったのです。

私は、その様子を見ながら本当に驚きました。

自分がAIと話し合って決めた設計がコードになる。

そのコードを確かめるテストコードもできる。

そして、実際にテストが走る。

「AIはプログラムを書けるらしい」

と外から眺めていたときとは、 まったく違いました。

その体験の重さは、 想像していたものとは違いました。

６．ものを作る時間の流れが変わった

そして、私が一番強く感じたのは、その速さでした。

それぞれの工程に、人の作業時間が必要でした。

もちろん、AIを使っても、 こうした工程そのものが全部なくなるわけではありません。

違ったのは、

私が、

「この場合はどうなる？」

と問いかける。

AIが設計を確認する。

コードを書く。

テストを書く。

テストを実行する。

必要なら修正する。

そして、また次へ進む。

これまで別々の工程だったものが、 対話の中で次々につながっていきました。

私が現役のころに接してきたシステム開発の時間感覚とは、 明らかに違いました。

私は、

「便利になった」

とか、

「少し速くなった」

という感覚では受け止められませんでした。

そう感じました。

７．AIは、模擬SharePointまでPythonでつくった

さらに驚いたことがありました。

ユニットテストをするとき、 毎回本物のSharePointへ接続していたわけではありません。

たとえば、

• このフォルダは存在するか
• フォルダをつくったらどうなるか
• どんな権限が設定されているか

といったSharePointの振る舞いを、 テスト用のPythonコードの中で再現します。

そして、その模擬SharePointを相手に ユニットテストを実行する。

いわば、小さな「模型のSharePoint」です。

つまりAIは、

ところまでやっていたのです。

私はここでも、

と感じました。

コードをつくる。

そのコードを試すための世界までつくる。

そしてテストする。

だからこそ、

というサイクルを、 ものすごい速度で回すことができるのだと思いました。

８．ところが、本物のSharePointでは違った

ところが、これだけテストしていても、 本物のAzureとSharePointで動かすと問題が見つかりました。

その一つが、SharePointの権限でした。

最初のコードでは、

「Full Control」

「Edit」

「Read」

という英語の名前を使って、 SharePointの権限レベルを設定しようとしていました。

ところが、私が実際に使っているのは 日本語版のSharePointです。

本物のSharePointから返ってくる表示名は、 日本語でした。

では、なぜユニットテストでは、 この問題を見つけられなかったのでしょう。

９．テストも、同じ前提でつくられていた

理由は単純でした。

プログラムは、

「Full Control」

を使おうとする。

模擬SharePointも、

「Full Control」

を返す。

だから、ユニットテストはPASSします。

テストの中だけを見れば、何も間違っていません。

ところが、本物の日本語版SharePointでは、 権限の表示名が日本語で返ってきました。

そこで初めて、

ことが分かりました。

これは、 ユニットテストが役に立たなかったという話ではありません。

ユニットテストは、

「こちらが想定した条件の中で、コードが正しく動くか」

を確かめることには、とても役立ちます。

ただし、

今回、私はそれを実際に体験しました。

そこでAIは、 英語や日本語といった表示名に頼るのではなく、 言語に左右されない方法で権限を判定するよう コードを修正しました。

さらに、日本語環境でも正しく判定できることを確認する ユニットテストも追加しました。

最初のテストで見えていなかった現実が、 本物のSharePointで見つかる。

その現実を、今度はテストの中にも取り込む。

こうしてテストも、 少しずつ現実に近づいていきました。

１０．「やり直す」ことにも問題があった

もう一つ、 途中で処理に失敗した場合にも問題が見つかりました。

途中までフォルダができる。

その後で処理が止まる。

初めのコードでは、 その処理を同じ番号でもう一度実行しても、 失敗した結果を返すだけで、 その先へ進めない場合がありました。

そこで、

という形へコードを修正していきました。

この修正コードもAIが書きました。

実際のAzureやSharePointで動かすための コードやコマンドもAIが用意しました。

私は、それを実行します。

返ってきた結果やエラーをAIへ伝えます。

AIが原因を調べます。

コードを直します。

私はまた実行します。

ここでも同じ往復が続きました。

１１．AIがつくり、人間が現実に当てる

今回の開発を振り返ると、 人間とAIの役割について、 前回とは少し違うものが見えてきました。

前回は、

という関係でした。

今回は、その先へ進みました。

コードを書いたのは、AIです。

でも、完成品をAIから受け取って終わりではありませんでした。

そんな共同作業になりました。

１２．「もう一度、つくり直そう」のコストが下がった

前回の記事で、私は、

AIが変えたのは「考え直すコスト」だった

と書きました。

人間のチームで、

「要件まで戻りましょう」

「設計をやり直しましょう」

と言うのは簡単ではありません。

でもAIとの対話なら、

「待って。この場合はどうなる？」

と思ったところから、 すぐ前へ戻れます。

今回、その先を体験しました。

コードを書いたあとでも、

「この場合は？」

と聞く。

AIが直す。

テストする。

もう一度直す。

つまりAIは、

と言えるコストまで、 大きく下げ始めていました。

この循環そのものが、とても軽くなった。

私はそこに、 前回とはまた違う大きな変化を感じました。

１３．文明の夜明けに立ち会っている

今回の経験を、私は単に、

「初めてAIにコードを書いてもらった」

という出来事としては受け止めていません。

コードを全面的にAIが書いた。

テスト用の模擬SharePointまでPythonでつくった。

ユニットテストを書いた。

そのユニットテストまで実行した。

問題があれば、コードやテストを直した。

その一連のサイクルが、 驚くほどの速度で回っていった。

私はそれを、 ニュースでも、誰かのデモでもなく、 自分が本当につくろうとしている Digital Supporters Clubの開発で経験しました。

そして、その速度を目の前で見たとき、 私が現役のころに接してきたシステム開発との違いを、 頭ではなく実感として感じました。

だから私は、本気で、

そんな実感を持ちました。

AIによって、 単にプログラミングが便利になったのではない。

私はそう感じました。

私はプログラマーではありません。

プログラムも一行も書いていません。

それでも、

その「ものをつくる世界」の中に、 自分も入ることができました。

もちろん、AIが常に正しいわけではありません。

今回も、本物のSharePointへ当てたからこそ 分かったことがありました。

だから、人間の役割がなくなったとは感じません。

むしろ、

そう感じています。

Digital Supporters Clubのクラブサイトは、 まだ完成していません。

今回の出来事は、 第２章の本当にとっかかりです。

でも、そのとっかかりだけで、 私はこれまでとはまったく違う ものづくりの速度を経験しました。

前回、これからやろうとして書いたこの循環が、 もう実際に動き始めています。

AIと一緒につくる。

現実に当てる。

違っていたら、またAIへ返す。

そして、もう一度つくる。