記事一覧

2026-09-04 22:54:00

AIに「この作品は何のためにあるか」を渡す — 設定ファイル01の中身

AIと小説をつくる仕組み・全8回 第3回

――AIエージェント全員が戻る、いちばん上の基準をつくる

AIに「この作品は何のためにあるか」を渡す — 設定ファイル01の中身

AIと小説をつくる仕組みを紹介する、全8回連載の第3回です。

前回の 「設定ファイルを16個に分けた話」 では、作品の情報を分けて管理する全体像を紹介しました。 今回は、その入口となる 「作品の目的と前提」 を取り上げます。

この連載でいうAIエージェントは、 執筆や評価などの役割と指示を受けて作業するAIです。

そのAIに小説を任せるとき、最初に共有したいのは、 作品が何を目指しているかです。

登場人物の名前やあらすじだけでは、 場面をどう描き、何を基準に直すかの判断まではそろいません。

そこで用意しているのが、 「作品の目的と前提」という設定ファイルです。 AIが作品世界に入るための入口であり、 判断に迷ったときに戻る基準でもあります。

最上位の目的を共有する

『13歳、わたしはお金持ちになると決めた。100の問い』では、 最上位の目的を 「人間が変わる一回分を、物語としてシミュレートすること」 と定めています。

登場人物をある状況に置く。 そこから感情が生まれ、小さな行動につながる。 行動には結果が返り、問いが残る。 このつながりを、各回の土台にしています。

設定ファイルでは、品質の物差しを 「人間は本当にこう変わるか」 としています。

読み違えたり、体験をうまく言葉にできなかったりすることも、 その人物にとって自然なら残します。 執筆担当にも評価担当にも、この基準を渡します。

実際に、Q44のv2の評価で指摘されたのは、 地の文の採点癖でした。

理由になっているような、なっていないような答えだった。

この一文は、登場人物の答えを、 読者が受け取るより先に地の文が採点しています。

答えの曖昧さをそのまま置けば、 読者は会話から自分で受け取れます。 ところが、語り手が評価を添えると、その余白が狭まります。

興味深いのは、この一文が 総合88点の稿にも残っていたことです。

点数上の承認基準は85点以上で、 評価レポートでも承認可能とされていました。 それでもv4で再び指摘され、 最終的な確定稿で削除しました。

v4で指摘された地の文は3か所あり、 削除したのは2つ、1つは残しています。

「理由になっているような、なっていないような答えだった」と 「閉じても、遅かった」は削除し、 「長く感じた」は残しました。

点数だけで判断が決まるわけではありません。

AIの指摘を受け取り、 「人間は本当にこう変わるか」という最上位の目的に照らして、 最後は書き手が選びます。

作品の目的を共有する意味は、こうした検討にもあります。

「経験の意味を説明しすぎない」という文体の規則とつなげることで、 AIは具体的な一文を指摘できる。 書き手も、その指摘を採用するかどうかを、 作品全体の基準に戻って考えられます。

人物が持ち込む願いを渡す

作品の目的だけでは、人物ごとの動きは決まりません。 そこで、このファイルには、 二人が物語に持ち込む願いも記しています。

人物 出発点 相手の家庭に求めるもの
ルミ お金があれば遠慮しなくていい 経営の知恵や、成功した環境
莉子 好きなことがわからない 愛と調和のある温かさ

二人は同じ目標へ向かっていても、 同じものを求めているわけではありません。 その違いが、協力にもすれ違いにもつながります。

AIには、こうした背景を 台詞や行動を選ぶ根拠として使ってもらいます。

人物の性格を「明るい」「慎重」といった言葉で覚えるだけでなく、 何に惹かれ、何を手に入れようとしているのか まで共有しておくためです。

物語全体の到達点も記しています。

本作では、二人がパン屋さんを事業として成功させ、 その後に、成功だけでは対処できない出来事へ向き合います。

この順序を共有しておかないと、 目の前の回を盛り上げるための変更が、 長期的な設計を崩しかねません。

GraceというAIコーチの役割も、その前提のひとつです。

前半はルミに問いを返し、 後半は二人の実践を支える共同コーチになります。 支援の方法が変わっても、 選択と行動の主体は二人に残ります。

ここを共有することで、 Graceの提案だけで物語が進むことを防ぎます。

AIに伝えることと、読者に伏せること

設定ファイルには、 作品の奥にある問いや終盤の設計まで記しています。 執筆するAIには、全体を理解してもらう必要があるからです。

ただし、 それを本文のどこで読者に伝えるかは別の判断です。

たとえば、莉子がルミの家庭に何を求めているのかは、 制作側が共有する情報です。

本文では莉子の内面を直接説明せず、 言葉、視線、動作、沈黙を通して描きます。

AIが背景を知っているからといって、 その知識を地の文に書いてよいわけではありません。

作品が最後に向き合う問いも同様です。 読者には、まず二人の商売や関係の行方を追ってもらいます。

テーマを先回りして説明すると、 出来事に直面して考える機会を奪ってしまいます。

設定ファイルには、 「知っておくべきこと」と 「まだ書いてはいけないこと」の両方 が必要です。

全体を知るAIが、 その時点のルミに見える範囲で場面を書く。 その境界を支えるのも、このファイルの役割です。

他のファイルとつなげて使う

「作品の目的と前提」には、 すべての指示を詰め込んでいません。

人物の詳細、禁止事項、文体、各回の場面設計、 確定済みの出来事は、 それぞれ別のファイルで管理しています。

このファイルは、 それらを読むときの共通の土台です。

Q44の例でも、 作品の目的だけで修正箇所が決まるわけではありません。

「経験の意味を説明しすぎない」という文体の規則と照らし合わせることで、 具体的な一文への指摘になります。

大きな目的と細かな規則をつなげて使うことが、 執筆と評価の判断をそろえます。

担当するAIや執筆する回が変わっても、 「この作品は何を目指しているのか」に戻れるようにする。

そのために、作品世界への入口をファイルとして用意しています。

該当する設定ファイル

01_premise.md

作品の最上位の目的、核心となる問い、 ルミと莉子の出発点、二つの家庭の対比、 パン屋さんの位置づけ、Graceの役割、 読者に届けたい体験、物語の到達点をまとめています。

AIエージェントが場面を書く前に読み、 作品全体の方向を確認するためのファイルです。

関連する 00_priority.md は、 設定同士が食い違った場合の優先順位を定めています。

後半の詳細は、 14_simulation_phase_q51_100.md が Graceとの共同実践や終盤の進め方を、 15_mobile_bakery_reality.md が パン屋さんの責任体制、安全、採算、成功条件を定めています。

2026-09-02 22:01:00

AIに長編小説を書かせ続けるために、設定ファイルを16個に分けた話

AIと小説をつくる仕組み・全8回 第2回

――人間が毎回していた確認を、AIエージェントの制作工程に変える

生成AI、役割を分けたAIエージェント、設定ファイル、人間の判断の関係を表したインフォグラフィック
設定ファイルを共通の基準にして、執筆・評価・整合性確認を分担し、最後は人間が判断します。

この記事の要点

生成AIは、同じ指示からも毎回少しずつ違う文章を作ります。 長編では、その小さな違いが人物や時系列の矛盾として積み重なります。 そこで私は、人間が毎回行っていた確認を役割に分け、 執筆・4つの評価・整合性確認・統合をAIエージェントに担当させました。

全エージェントが同じ作品へ戻れるよう、『13歳、わたしはお金持ちになると決めた。100の問い』Q1〜Q50では設定を16個のファイルに分けて管理しました。 実際に起きた修正と見逃しの両方から、設定ファイルを運用する意味とコストを紹介します。

この記事を貫く4つのポイント
  1. 文章生成とエージェント執筆は、作業の範囲が違う
  2. 設定ファイルは、複数のAIが共有する判断基準になる
  3. Q44では、初稿84点が改稿で88点になり、さらに過去稿との照合で二つの不整合を直した
  4. 16ファイルの運用には、更新漏れや古い設定を残すリスクもある

1.AIによる文章生成と、AIエージェントによる執筆の違い

生成AIに「小説を書いてください」と頼めば、文章はすぐに生成されます。

ただし生成AIは、完成した答えを保管場所から取り出しているのではありません。 入力された指示や資料を文脈として読み、次に続く言葉の候補を確率的に選びながら文章を組み立てます。

同じ指示を与えても、
言葉、場面の順序、会話、結末まで同じになるとは限りません。

この性質は、短い文章では表現の豊かさになります。 一方、長編小説では小さな違いが積み重なり、人物の性格、過去の出来事、日付、伏線などのずれになります。

チャットで小説を書き始めたころ、AIが原稿を出すたびに、私は次のことを人間の目で確認していました。

  • ルミと莉子の性格や話し方が変わっていないか
  • 前の回で起きた出来事と矛盾していないか
  • 莉子の内面を、ルミには分からない地の文で説明していないか
  • 物語の問いを、登場人物が教訓として説明していないか
  • 会話や情景が、作品の文体から外れていないか

つまり私は、依頼者であると同時に、編集者、校閲者、設定管理者、初見読者の役割も引き受けていました。

そこで、この確認作業を分解し、それぞれに参照資料と手順を与えました。 これが、私の小説制作におけるAIエージェントです。

AIエージェントによる小説制作工程 執筆した原稿を4つの視点で評価し、整合性を確認してから評価を統合し、最後に人間が判断する流れ 執筆エージェント 4つの評価エージェント 創造性 読者体験 会話 情景 整合性を確認 評価を統合 最後は人間が判断
AIが自動的に完成を決めるのではなく、役割ごとの結果を材料に、改稿するか承認するかを人間が決めます。

2.設定ファイルはAIエージェントのガードレール

役割を分けても、それぞれのエージェントが別の作品像を持っていたら、判断は安定しません。 全員が同じ基準へ戻るために必要なのが設定ファイルです。

設定ファイルは、AIに覚えさせるためのメモではなく、
迷ったときに参照する作品の判断基準です。

道路のガードレールは、車の進む方向を一つに固定するものではありません。 進む自由を残しながら、越えてはいけない境界を示します。

小説の設定ファイルも同じです。 AIに会話や情景を考える自由を残しながら、人物の核心、視点、時系列、禁止事項から外れたときに、同じ作品へ戻します。

たとえば、この作品の文体を定める style_constitution.md には、実際に次のように書いてあります。

文体はシンプル
感情を直接書かない
行動・沈黙・環境描写で感情を示す
行間に感情が流れる文章にする

これは「美しい文章を書いて」という抽象的な依頼ではありません。 執筆担当には書き方の境界を示し、評価担当には原稿を判定する基準を渡しています。

Q44で、過去稿とのずれを二つ直した

設定ファイルが実際に働いた例が、問い44「『ありがとう』はどれくらい伝えてる?」です。 「ありがとう」を問うこの回で、ルミは莉子に八つ当たりをします。

Q44を改稿していた段階で、ルミの八つ当たりの中に、過去の「ヒナタ」の出来事を入れる案がありました。 しかしQ8の確定稿と照合すると、現在の場面からその言及へつなぐと、過去に起きたことの扱いがずれます。 そこで、ヒナタへの言及は使わないと決め、13_details.md に記録しました。

もう一つは、自動販売機です。 Q44では、過去の場面を響かせるためにミルクティーの見本を出す案がありました。 ところがQ17とQ29の確定稿を読み直し、同じ自動販売機に重なっている二つの記憶を整理した結果、 Q44では「りんごジュースの缶」を使うことにしました。

過去の要約や記憶から場面を作る

Q8・Q17・Q29の確定稿と照合する

ヒナタへの言及を削除する

ミルクティーを、りんごジュースの缶へ修正する

判断と教訓を 13_details.md に残す

Q44の初稿は総合84点でした。 この総合点は、創造性、初見の読者体験、会話の複雑さ、情景と感情という4つの評価を加重平均して算出しています。 承認基準は85点以上です。84点は改稿、88点で承認可能という意味になります。

4つの評価で指摘された八つ当たりの長台詞、比喩による感情の説明などを修正した次の稿は88点になりました。 整合性確認は総合点には加えず、作品の重大な矛盾を止める別のゲートとして通過判定を行います。 このゲートで、過去の実発話との差を含む初稿のずれが解消されたことも確認しました。

その後の作者編集で、確定稿をさらに照合し、ヒナタへの言及を削除して、ミルクティーをりんごジュースの缶へ変更しました。 84点から88点への上昇と、この二つの不整合修正は、同じQ44の制作中に起きた別の改善です。

Q44は、4評価による改稿で84点から88点へ。
その後、過去稿との照合による二つの修正も設定へ残しました。

ここで得た一番大きな教訓は、AIや人間の記憶から過去を再現しないことでした。 過去の場面に依存する描写は、要約ではなく確定稿そのものと照合する必要があります。

3.設定ファイルの基本構成と、実際の運用コスト

設定ファイルは、情報を多く書けばよいわけではありません。 AIが必要なときに、正しい基準と現在地を見つけられる構造にする必要があります。

設定の種類 記録する内容 主な目的
作品の核 目的、前提、全体構造、100の問い 何のための物語かを見失わない
人物と世界 人物、欲望、弱点、関係、場所 人物らしさと舞台を保つ
表現のルール 視点、文体、表記、禁止事項 文章の手触りと境界を守る
場面の設計 各章の出来事、固定アンカー、場面の核 全体構成を一回分の場面へ落とす
物語の現在地 確定した出来事、日付、数値、小道具 古い情報との混同を防ぐ
確認の基準 人物、文体、整合性のチェック項目 人間がしていた確認を再現する

運用では、変わりにくい設定と、毎回更新される現在地を分けています。

変わりにくい設定
作品の目的・人物の核心・視点・禁止事項

更新される現在地
出来事・日付・数値・関係の変化・小道具の状態

一回分の原稿を承認するときは、本文を確定するだけでは終わりません。 時系列を管理する 10_timeline.md と、確定事実を管理する 12_glossary.md も同時に更新します。

この作業には明確なコストがあります。 16個に分ければ自動的に安全になるわけではなく、更新する場所が増え、古い記述を残す危険も増えます。

Q49では、矛盾が確定稿まで残った

実際、Q49では「この高校、大学まであるんだって」「内申って、2年から関係ある?」という、 高校受験を前提にした会話が確定稿まで残りました。

しかし、ルミと莉子の学校は私立の中高一貫校です。 作品の学校設定と、場面で使った進路の話題が一致していませんでした。

この矛盾は、設定ファイルがあれば失敗しない、という話ではないことを示しています。 ファイルがあっても、読む範囲、照合の順序、更新のタイミングが足りなければ、矛盾は通過します。

しかもQ49は、すでに公開された確定稿でした。 既刊を購入した読者がいる以上、手元の本文だけを黙って書き換えれば、同じ作品に異なる内容が併存してしまいます。 そこで本文を修正せず、12_glossary.md に「既知の差異」として登録しました。 以後は高校受験や内申を前提にした描写を広げず、進路の話題をコース分け、学年順位、模試、塾、その先の大学に限る運用にしました。

設定ファイルは、失敗をゼロにする魔法ではありません。
失敗を発見し、次の回へ広げず、修正方針を共有するための仕組みです。

Q44では改稿の精度を上げることができました。 Q49では見逃しも起きました。 成功例と失敗例の両方を残すことで、どの確認工程を強くするべきかが見えるようになります。

4.Q1〜Q50で使った16個の設定ファイル

『13歳、わたしはお金持ちになると決めた。100の問い』では、 一つの巨大なプロンプトに設定を詰め込まず、Q1〜Q50を次の16個のファイルで支えました。

ここでいう「16個」は、役割上の16種類という数え方です。 09_scene_plan_chX.md は一種類として数えていますが、実体は章ごとに作成・更新します。

ファイル 実際の役割
00_priority.md 設定同士が衝突したとき、どの指示を優先するかを決める
01_premise.md 作品の目的、前提、物語の中心となる考えを定める
02_characters.md ルミ、莉子、家族の人物像、欲望、弱点、言動の境界を管理する
03_structure.md 100の問いを10章へ配置し、物語全体の進行と転換点を示す
04_style.md ルミの三人称視点と、書いてよい内面の範囲を定める
05_questions_bank.md 各問いの番号、章との対応、物語内での問いの扱いを管理する
06_locations.md 家、学校、街などの場所と、その場所が持つ条件を記録する
07_forbidden.md 直接説明しないテーマ、避ける表現、越えてはいけない描写を定める
08_style_guide.md 実際の原稿から、文章の長さ、改行、会話、数字表記を具体化する
09_scene_plan_chX.md 各章を場面へ分解し、必ず入れる固定アンカーと表現メモを区別する
10_timeline.md 季節、日付、経過時間、各回で起きた出来事の順序を管理する
11_friendship_arc.md ルミと莉子の友情が、一方通行から双方向へ変わる過程を追う
12_glossary.md 確定した数値、呼称、小道具、関係の現在状態、既知の差異を管理する
13_details.md 描写の取材情報を確定・未確認・検証済みに分け、失敗から得た教訓も残す
style_constitution.md 文体と描写の憲法。感情を説明せず、行動・沈黙・環境から立ち上げる
character_check.md 主人公が自分から動き、欲望と弱点が場面に現れているかを確認する

ファイルを分ける目的は、AIに大量の情報を読ませることではありません。 執筆、評価、整合性確認のそれぞれが、必要なときに必要な正しい情報へ戻れるようにすることです。

ファイルの数より大切なのは、
何を正とし、いつ読み、いつ更新するかを決めることです。

Q1〜Q50では、グレースはルミの相談相手でした。 物語の中心は、ルミが莉子や家族との関係の中で体験し、行動し、その結果として問いを見つけることでした。

Q51以降では、グレースの役割も物語の進め方も変わります。 相談相手から、ルミと莉子にドリルを出し、結果に応じて計画を組み直す共同コーチへ。 そして物語は、移動式パン屋を現実の事業として立ち上げるシミュレーションへ移ります。

その転換に合わせて、どの設定を残し、どの設定を区切り、何を新しく加えたのか。 次の記事から、設定ファイルを詳しく紹介します。

今回参照した制作資料

  • Q8、Q17、Q29、Q44、Q49の確定稿と評価レポート
  • 13_details.md のQ44場面シートと更新履歴
  • 12_glossary.md の確定事実、関係の現在状態、既知の差異
  • style_constitution.md とQ1〜Q50の作品設定ファイル
  • 執筆・4評価・整合性確認・統合評価のエージェント定義

この記事は、生成AI一般の唯一の使い方を示すものではありません。 一つの長編小説をAIと継続して制作するために、私が実際に組み立て、失敗しながら更新してきた方法 をもとにまとめています。

2026-08-27 20:01:00

AIと一緒にMicrosoftの道具箱をひっくり返してみた

AIと一緒にMicrosoftの道具箱をひっくり返してみた

――会員サイトを作ろうとして見えてきた、つながる仕組み

会員サイトの設計をもとに、SharePoint、Teams、Forms、Power Automate、Entra ID、Purview、AzureなどMicrosoftのサービスをつないでいく仕組みを表したインフォグラフィック
会員サイトの設計を先に考え、その実現に必要なMicrosoftの道具を一つずつ探してつないでいきました。

この記事の要点

Digital Supporters Clubの会員サイトを作るために、 まず設計書を書き、その設計を実現する道具をMicrosoftの製品群から探していきました。

そこで分かったのは、Microsoft 365にはたくさんの機能が揃っているだけではなく、 管理者側で認証や権限の仕組みを理解すると、それぞれをつなげて一つのサービスとして使える ということでした。

そして今は、分からないことを一緒に調べ、設計し、試してくれる ChatGPTやClaudeのような「技術に詳しい同僚AI」がいます。

プログラマーとして仕事をしてきたわけではない私でも、 AIと一緒に確認しながら、実際に仕組みをつないで動かすところまで体験できました。

この記事を貫く4つのポイント
  1. 最初に作ったのは、Microsoftの勉強計画ではなく会員サイトの設計書
  2. Microsoftの強さは「道具が多い」だけでなく「道具同士がつながる」こと
  3. 管理者側を理解すると、認証・権限・監査まで含めて一つの仕組みにできる
  4. AIと一緒なら、知らない技術も調べ、確認し、試しながら理解できる

1.最初に作ったのは、会員サイトの設計書だった

Digital Supporters Clubでは、

「AIと、一緒に。書いてみたいことを、形にしよう。」

という考え方で、小説、エッセイ、自分史、思い出、体験などを書いてみたい人が、 少しずつ自分の言葉を形にしていける場所を作ろうとしています。

今回の出発点は、 Microsoft 365を勉強することではありませんでした。

最初に考えたのは、

どんな会員サイトにしたいのか

ということです。

会員には、自分だけの原稿を書く場所がある。

書いたものを保存して、続きを書ける。

完成した作品は、ほかの会員に公開できる。

ほかの会員は作品を読めるけれど、 勝手に編集することはできない。

読んだ人は感想を残せる。

作品を取り下げても、元の原稿は残す。

届いた感想も大切に残す。

こうしたことを一つずつ設計書に書いていきました。

会員サイトの中心となる体験は、

書く

保存する

続きを書く

公開する

感想が届く

また書く

という流れです。

つまり、 製品から考えたわけではありません。

先に「こうしたい」という設計があり、
そのあとで必要な道具を探した。

この順番でした。

設計ができたところで、

「さて、これを実現するには何を使えばいいのだろう」

と、Microsoftの道具箱をひっくり返してみました。

2.中心に置いたのはSharePointだった

最初に中心になったのはSharePointでした。

以前の私にとってSharePointは、 どちらかというと、

会社でファイルを共有する場所

という印象でした。

ところが、自分で管理者側から触ってみると、 ずいぶん違って見えました。

文書を保存できる。

フォルダを作れる。

履歴も残せる。

そして、 誰に見せるのか、 誰に編集させるのかを細かく決めることができます。

そこでDigital Supporters Clubでは、 SharePointの中に、

自分の作品を書く
本人専用

みんなの作品
会員向け公開

という二つの場所を分けて作ることにしました。

本人専用の場所は、 本人と管理者だけがアクセスできます。

公開側では、 作者は自分の作品を編集できる。

ほかの会員は読むことはできるけれど、 編集することはできない。

つまりSharePointを単なるファイル置き場としてではなく、

会員サイトの情報と権限の中心

として使うことにしました。

ここまで来ると、 次の疑問が出てきます。

入会申込はどうするのか。

会員をどう識別するのか。

承認はどうするのか。

感想はどこで受け取るのか。

管理作業が増えたらどうするのか。

そこで、Microsoftの道具箱をさらにひっくり返していきました。

3.道具箱から、これだけのものが出てきた

今回の会員サイトづくりで登場した主なMicrosoftのサービスを並べてみます。

自分でも、こうして一覧にすると驚きます。

製品・機能 今回の役割
SharePoint Online 会員サイトの中心。原稿、公開作品、アクセス権を管理する
Microsoft Teams お知らせや、作品への感想をやり取りする
Microsoft Forms 入会申込を受け付ける
Power Automate Forms、承認、通知などの処理をつなぐ
Approvals 管理者が入会を承認・却下する
Microsoft Entra ID 会員やアプリの「身元」と「できること」を管理する
Microsoft Graph Microsoft 365の情報をプログラムから扱うための窓口
SharePoint REST API SharePointをプログラムから操作するための窓口
Microsoft Purview Audit Microsoft 365上で行われた操作の記録を確認する
Azure Functions DSC Builderのプログラムを動かす
Azure Key Vault 証明書やAPIキーなどの秘密情報を保管する
Managed Identity Azureのサービス同士を、パスワードを直接渡さず認証する仕組み
Application Insights プログラムの実行結果やエラーを確認する
Sites.Selected アプリが操作できるSharePointサイトを限定する仕組み

もちろん、 これらすべてがMicrosoft 365 Business Basicの料金だけに含まれているわけではありません。

Azure FunctionsやKey Vaultなど、 Azure側のサービスは別途従量課金です。

Purviewについても、 利用できる機能やログの保持期間などはライセンスによって異なります。

それでも、 会員サイトの中心となるSharePoint、Teams、Formsなどを、 比較的低価格なMicrosoft 365のプランから使い始めることができます。

2026年8月現在、 Teamsを含むMicrosoft 365 Business Basicは、 Microsoft公式サイトで年間契約の場合、

1ユーザーあたり月額1,049円相当、税別

と案内されています。

最近は、お昼を食べても1,000円を超えることが珍しくありません。

ランチ1回ほどの金額で、 これほど大きな道具箱を毎月使える。

これは、あらためて考えるとかなりすごいことだと思います。

Microsoft公式「Microsoft 365 Business Basic」

4.本当に驚いたのは「道具の数」ではなく「つながること」

ただ、今回いちばん驚いたのは、 Microsoftに製品がたくさんあることではありませんでした。

それらを、つなげて使えることです。

Digital Supporters Clubでは、 たとえばこんな流れになります。

Microsoft Forms
入会申込



Power Automate / Approvals
管理者による承認



Microsoft Entra ID
会員を識別



SharePoint
書く・保存する・公開する



Teams
感想を受け取る



Azure Functions
管理作業を支援する



Key Vault
秘密情報を守る



Application Insights
処理結果を確認する



Microsoft Purview Audit
利用の記録を見る

Purviewでは、 Microsoft 365上で行われた操作の記録を確認できます。

Digital Supporters Clubでは将来的に、 SharePointのページを見た、 ファイルを開いた、といった記録から、

「この会員が最後にDigital Supporters Clubを利用したのはいつか」

を確認することまで設計しています。

現在の試作では、 まずSharePointの読み取りと新規会員セットアップまでを作っています。

Purviewとの自動連携は、 その試作を評価してからの次の段階です。

それでも、

入会する

本人を識別する

書く

保存する

公開する

感想を受け取る

管理する

何が起きたかを記録する

ここまでをMicrosoftのサービスで一本につなげられる。

これが、 道具箱をひっくり返してみて一番驚いたことでした。

5.管理者側に立って、初めて「つなげ方」が見えた

そして今回、 もう一つ大きな発見がありました。

それが、

Microsoft 365を管理者側から見たこと

です。

大きな組織や行政でMicrosoft 365を使っていると、 管理者の仕事は情報システム部門やベンダーが担当することが多いと思います。

一般の利用者には、 必要な機能だけが提供されます。

Teamsはこちら。

SharePointはこちら。

このフォルダを使ってください。

それは、安全に運用するためには当然のことです。

ただ、それだけを使っていると、

Microsoft 365という仕組みが、本来どこまでできるのか

は、なかなか見えてきません。

私自身もそうでした。

今回、自分で管理者側に入り、

  • 外部の人をどう参加させるのか
  • 誰にどの権限を与えるのか
  • アプリからSharePointへどう接続するのか
  • アプリにはどこまで操作を許すのか
  • 何が行われたかをどこで監査するのか

と、一つずつ見ていきました。

そこで初めて分かったことがあります。

サービス同士をつなぐには、
機能を知っているだけでは足りない。
認証と権限を理解する必要がある。

FormsとPower Automateをつなぐ。

Entra IDとSharePointをつなぐ。

Azure FunctionsとMicrosoft 365をつなぐ。

Purviewで、その利用記録を見る。

こうした接続には必ず、

  • 誰が接続しているのか
  • 何をすることが許されているのか
  • どこまでアクセスしてよいのか

という問題が出てきます。

ここを理解できるようになったことで、 Microsoftの各製品が、 ばらばらのアプリではなく、

一つのシステムを作るための部品

として見えるようになりました。

そして管理者権限についても、 印象が変わりました。

管理者権限は、 何でもできるようにするための権限ではありません。

必要な人に、必要な範囲だけ権限を与えるために使う。

今回のDSC Builderでも、 Microsoft 365全体を自由に操作できるようにはしていません。

Digital Supporters ClubのSharePointサイトだけに、 操作できる範囲を限定しました。

管理者側を知ることで、

「何ができるか」だけではなく、
「どこまでできるようにするか」を設計できる。

そして、それがサービス同士を安全につなぐことにつながります。

6.APIも、実際につないでみて分かった

サービス同士をつないでいく中で、 これまで少し遠い言葉だった「API」の意味も、 だんだん実感として分かるようになりました。

APIとは簡単に言えば、

プログラム同士が情報をやり取りするための窓口

です。

普段Webサービスを使っていると、 私たちが見るのは表側です。

ブラウザを開く。

ボタンを押す。

入力する。

保存する。

その裏側で、 プログラム同士がどう話しているのかを見る必要はありません。

今回、自分でDSC Builderを作って、 初めてAPIが実感として分かりました。

私がAIに、

「この会員のSharePointフォルダを準備して」

と頼む。

AIが専用APIへ依頼する。

Azure Functionsで動いているプログラムが、 SharePointのAPIへ依頼する。

SharePointが処理する。

そして結果が戻ってくる。

そこで、

「ああ、APIというのは、プログラム同士が話をするための窓口なんだ」

と腑に落ちました。

教科書で定義を読むより、 自分でつないで動かしてみる方がずっと分かりやすかったのです。

Azureについても同じでした。

プログラムを動かす
Azure Functions

秘密情報を守る
Key Vault

実行状況を見る
Application Insights

というように、 必要な機能をサービス単位で組み合わせました。

Azureを使っているのに、 あまり「サーバーを作っている」という感覚がありません。

これも実際に触ってみて初めて分かったことでした。

7.AIは、技術に詳しい同僚のようだった

ここまでできた背景には、 もちろんAIがあります。

私はプログラマーとして仕事をしてきたわけではありません。

今回も、

  • API
  • REST
  • Entra ID
  • 証明書認証
  • Managed Identity
  • Sites.Selected

と、知らない言葉が次々に出てきました。

以前なら、 そのたびにマニュアルを探していたと思います。

説明を読む。

分からない言葉が出てくる。

その言葉を検索する。

すると、また知らない言葉が出てくる。

どこかで、

「これは自分には難しい」

と思っていたかもしれません。

今は、ChatGPTやClaudeに、

  • 「そもそもAPIって何?」
  • 「なぜここに認証が必要なの?」
  • 「この権限は広すぎない?」
  • 「今の構成を初心者にも分かるように説明して」

と、その場で相談できます。

そして、 単に答えを教えてもらうだけではありません。

一緒に設計を考える

設定する

エラーの原因を考える

公式資料を調べる

実際に動かして確認する

また修正する

今回の感覚に近いのは、

技術に詳しい同僚AIが隣にいて、一緒に作業している

というものでした。

もちろん、 AIの答えがいつも正しいとは限りません。

特に認証や権限、 Microsoftのサービス仕様のような重要な部分は、 Microsoftの公式資料を確認し、 最後は実際の環境で動作を確かめる必要があります。

今回も、

AIに聞く

公式情報を確認する

実際に試す

結果を見る

ということを何度も繰り返しました。

AIに全部任せるのではなく、

詳しい同僚と一緒に考えながら、
自分自身も理解していく。

そんな使い方が、 確かに私には合っていました。

8.今回一番大きかったのは、管理者側を自分で触ったこと

今回の会員サイトは、 まだ開発の途中です。

でも、0次開発をやってみて、 自分の中ではMicrosoft 365の見え方がかなり変わりました。

以前なら、

SharePointはファイル置き場
Teamsは会議やチャット
Azureはエンジニアが使うもの
APIはプログラマーの世界
管理者画面は専門家やベンダーが触るもの

そんなふうに、 別々のものとして見えていました。

今回、先に会員サイトの設計書を書きました。

その設計を実現するために、 Microsoftの道具箱をひっくり返しました。

必要な道具を見つけました。

そして管理者側に入り、 認証や権限を理解しながら、 それぞれをつないでみました。

分からないところはAIと一緒に調べました。

公式資料でも確認しました。

そして実際に動かしました。

そこで一番強く感じたのは、

Microsoft 365は、
用意された機能を利用者として使うだけでは、
ほんの一部分しか見えない。

ということです。

もちろん、 組織で利用するときに管理者権限を誰にでも渡すべきだとは思いません。

強い権限だからこそ、 厳しく管理する必要があります。

ただ、自分で何かサービスを作ろうとするなら、

管理者側で何ができるのかを、
自分自身でも理解しておくことはとても大切だ。

と今回あらためて感じました。

管理者の部分をすべてベンダーに任せれば、 安全で楽な面もあります。

でも、それだけでは、

  • このサービスと、このサービスはつなげられる
  • ここまで権限を絞れる
  • このログを使えば、こんな運用ができる

という発想そのものが出てこないことがあります。

今回、管理者権限を持ってMicrosoft 365の中を実際に見たことで、

たくさんの道具があることだけでなく、
その道具をどう安全につなげれば
一つのサービスになるのか

が、少しずつ分かってきました。

月1,000円ほどのMicrosoft 365の道具箱。

必要な分だけ使えるAzure。

そして、 分からないところを一緒に考えてくれる同僚AI。

これらも大きな助けでした。

でも、今回の経験から私が最後に残したいのは、 もっと単純なことです。

自分でサービスを作りたいなら、
管理者側を人任せにしすぎず、
一度は自分で触って、何ができるのかを知っておく。

そして、 強い権限だからこそ、 その意味を理解し、 必要な範囲に絞って使う。

そのことの大切さを、 Digital Supporters Clubの会員サイトづくりを通して、 あらためて実感しました。

参考にした公式情報

この記事は、Microsoft製品を網羅的に解説することを目的としたものではありません。 Digital Supporters Clubの会員サイトを実際に設計し、必要なMicrosoftのサービスを一つずつつないでいった体験 をもとに書きました。
さて、Club会員サイトのメーキングストーリーはこのぐらいでお終いにします。
次回以降は、AI小説制作のテクニカルなお話をしたいと考えています。

2026-08-23 20:51:00

Claude in Chrome と GPTを比べてみた

Claude in Chrome と GPTを比べてみた

――AIに仕事を任せる、二つのまったく違う方法

Claude in ChromeとGPTという二つのAIエージェントの仕組みや特徴を比較したインフォグラフィック
ブラウザを直接操作するClaude in Chromeと、APIを通じて専用の仕事を行うGPT。二つは同じAIエージェントでも、設計思想が大きく異なります。

この記事の要点

前回までの記事で、Digital Supporters Clubの運営を支援する 「DSC Builder GPT」をつくってきました。

SharePointに会員用のフォルダをつくり、 決められたアクセス権を設定し、 最後に本当に正しく設定されたかを確認する。

ようやく、実際に動くところまでたどり着きました。

そこで今回は少し視点を広げ、 私が実際に作ったり使ったりした二つのAIエージェントを比較します。

一つは、今回つくったDSC Builder GPTのように、 APIを通じて、あらかじめ決められた仕事を行うタイプ。

もう一つは、Claude in Chromeのように、 AIがブラウザを見ながら人間の代わりに画面を操作するタイプです。

これは「ClaudeとGPTのどちらのAIモデルが賢いか」という比較ではありません。

Claude in Chromeというブラウザ操作型のAIエージェントと、 Custom GPT+Actions/APIでつくった専用型AIエージェントの比較です。

この記事を貫く4つの比較軸
  1. GPT型は「サービスをAIへつなぐ」
  2. Claude in Chrome型は「AIがサービスへ出かけていく」
  3. 自由度と安全性では、手綱を置く場所が違う
  4. どちらが優れているかではなく、向いている仕事が違う

1.そもそもAIエージェントとは何なのか

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

自分の代理人として、実際の仕事までしてくれるAI

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

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

「これについて調べて」

「どうすればいい?」

「文章を書いて」

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

AIが答えてくれる。

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

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

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

「どうすればいい?」ではなく、
「これをやっておいて」と頼める。

たとえば、

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

と頼む。

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

私はこの、

「教えて」から「やっておいて」への変化

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

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

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

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

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

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

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

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

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

当時は、

これからChatGPTそのものが、一つの大きなプラットフォームになっていくのではないか

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

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

旅行のGPT。

会計のGPT。

教育のGPT。

会社独自のGPT。

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

考え方としては、

世の中のさまざまなサービスを、AIの側へつないでいく

方向です。

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

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

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

たとえば、

「DSC0007として、この会員を準備して」

と頼む。

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

API側では、

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

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

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

DSC Builderでは、さらに、

Plan

人間が確認

Apply

Verify

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

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

私が確認する。

それから実行する。

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

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

AIが走れる道路を先につくり、
その道路の上だけを走らせる。

そんな方法です。

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

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

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

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

その状態で、

「この設定を確認して」

「ここを変更して」

と頼む。

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

メニューを探す

クリックする

次の画面を開く

入力する

保存する

つまりGPT型が、

サービスをAIへつなぐ

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

AI自身が、サービスのところまで出かけていく

仕組みです。

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

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

言い換えるなら、

ブラウザそのものを、巨大な共通インターフェースとして使ってしまう

発想です。

5.二つを比較すると、こうなる

比較項目 DSC Builder GPTのようなAPI型 Claude in Chromeのようなブラウザ型
基本思想 サービスをAIへAPIで接続する AIが既存のWebサービスへ行く
操作方法 APIを直接呼び出す 画面を見てクリック・入力する
事前準備 API、認証、スキーマなどの開発が必要 拡張機能を使い、対象サイトへログインすれば始めやすい
開発知識 比較的必要 少なくて済む
操作できる範囲 あらかじめ定義した範囲 ブラウザで到達できる範囲が広い
自由度 低い 高い
実行速度 APIなので比較的速い 画面操作なので相対的に遅い
UI変更の影響 比較的小さい 画面構成変更の影響を受けやすい
APIのないシステム 原則として苦手 強い
同じ処理の反復 得意 可能だが画面状態に左右されやすい
操作範囲の制限 API側で強制しやすい 権限モード、サイト権限、ブラウザ権限などで管理
安全性の考え方 API・権限・処理フロー自体を設計段階で制限 Manual / Auto / Skipから承認・自動チェックのレベルを選択
結果検証 Expected / ActualをAPIで比較しやすい 画面や実行結果を再確認する形になりやすい
監査・ログ operationIdなどで構造化しやすい ブラウザ操作・実行履歴が中心になりやすい
向いている仕事 定型・反復・重要な業務 探索的・臨時・幅広いWeb作業
最大の魅力 確実性と制御 自由度と導入の簡単さ
最大の弱点 作るのが大変 自由である分、監督や安全設定が重要

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

システム設計の思想そのものが違う。

のです。

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

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

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

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

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

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

とも思いました。

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

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

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

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

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

目的の場所を探す

クリックする

反応を待つ

違う場所へ行ったら戻る

必要ならもう一度試す

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

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

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

それ以降、

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

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

この体験から、

毎回同じことをする管理作業なら、
自由に画面を操作させるより、
できる操作を最初から限定した専用の仕組みをつくった方がいいのではないか

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

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

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

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

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

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

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

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

Manual

操作ごとに人間の確認を求めながら進めるモードです。

Auto

Claudeに作業を進めさせつつ、 危険と判断された操作は安全分類器によって自動的にブロックするモードです。

Skip

確認や自動チェックを行わずに進めるモードです。

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

どこまで人間が手綱を握るかを、利用者が選ぶ

考え方になっています。

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

そもそも危険な操作へ行ける道を用意しない。

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

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

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

つまり、

ブラウザ型
広い世界を歩けるAIを、どう安全に監督するか

API型
歩ける世界そのものを、最初から狭く設計するか

という違いがあります。

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

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

GPTが登場した2023年には、

ChatGPTの中に、あらゆる専門アプリが集まってくる

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

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

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

これは、

AIがプラットフォームになる未来

です。

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

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

SharePointも、そのまま。

管理画面も、そのまま。

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

つまり、

既存のソフトウェアをAI向けにつくり直さなくても、
AIが人間向けの画面を使えばいい。

という未来です。

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

GPT型
AIのところへ、サービスを持ってくる

Claude in Chrome型
サービスはそのままにして、AIをそこへ送り込む

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

9.では、どちらが向いているのか

ここまで比較すると、

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

という話になります。

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

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

API型が向いている仕事

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

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

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

今の段階では、

定型業務は専用型。
探索的な仕事はブラウザ型。

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

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

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

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

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

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

10.Microsoftの仕組みを一通り使ってみて分かったこと

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

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

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

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

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

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

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

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

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

動かない。

直す。

また試す。

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

それでも、 自分がChatGPTへ、

「DSC0007を準備して」

と頼む。

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

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

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

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

重要なのは、

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

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

むしろ、

私たちはAIへ、どんな形で仕事を渡すのか。

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

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

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

どこまで任せるのか。

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

手綱を人間が握るのか。

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

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

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

アプリをAIの中へ集めなくても、
AIが今あるアプリを使いに行けばいい。

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

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

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

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

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

AIエージェントという言葉の中で、
すでにかなり違う未来の形が競い始めている。

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

2026-08-17 22:12:00

ものづくりの時間が変わった――「文明の夜明け」を感じた

ものづくりの時間が変わった――「文明の夜明け」を感じた

――SharePoint版への第2章、そのとっかかりで「文明の夜明け」を感じた

AIがコードを書き、模擬SharePointを構築し、ユニットテストを実行。人間が実際のSharePoint環境で確認し、AIへ結果を返して改善する開発の流れを表したイラスト
AIがコードを書き、ユニットテストまで実行。人間が本物の環境で確かめ、その結果をまたAIへ返していきました。

この記事の要点

私はいま、Digital Supporters Clubという会員制クラブサイトをつくっています。

前回は、Microsoft Power Pagesを使った会員サイトの設計に挑戦し、 AIとの対話を繰り返した結果、 要件定義書から123件のテストケースを持つテスト仕様書までつくりました。

そして次は、SharePointを中心に、 もっと小さく実際に動くものをつくってみよう、と方向を変えました。

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

SharePoint版の運営を少し楽にするために、 会員ごとのフォルダ作成や権限設定を支援する 「DSC Builder」という小さな管理ツールを、 AIと一緒につくることにしました。

そこで私は初めて、 AIに実際に動くコードを全面的に書いてもらいました。

驚いたのは、それだけではありません。

AIは、そのコードを確かめるためのユニットテストまで用意し、 実際にそのユニットテストまで実行したのです。

さらに、テスト用の模擬SharePointまでPythonコードとしてつくっていました。

コードを書く。
テストを書く。
テストする。
問題があれば直す。
またテストする。

そのサイクルが、 私が現役のころに接してきたシステム開発とは、 まるで違う速度で回っていきました。

私はその様子を見ながら、

「自分はいま、文明の夜明けに立ち会っているのではないか」

と本気で感じました。

ところが、ユニットテストが通ったコードを 本物の日本語版SharePointで動かすと、 それでも問題が見つかりました。

そこで見えてきたのは、

AIがつくり、人間が現実に当て、その結果をまたAIへ返す

という、新しいものづくりの姿でした。

この記事を貫く4つの気づき
  1. AIはコードを書くだけでなく、ユニットテストをつくり、実行するところまで進んでいる
  2. AIによって「設計 → 実装 → テスト → 修正」の速度が大きく変わった
  3. ユニットテストが通っても、本物の環境でなければ分からないことがある
  4. AI時代の開発では、人間は「現実との接点」という重要な役割を持つ

今回の経験で強く感じたのは、 AIが単にコードを書くようになったのではなく、 ものをつくり、試し、直し、もう一度つくる時間の流れそのものが変わり始めている ということです。

1.第2章へ踏み出したところで、驚いた

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

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

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

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

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

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

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

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

そして最後に、

Power Pagesへの挑戦が第1章。

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

そう書きました。

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

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

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

AIに実際に動くコードを全面的に書いてもらいました。

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

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

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

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

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

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

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

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

Power Pages版で考えた、

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

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

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

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

新しい会員が入る

会員専用のフォルダをつくる

原稿を書く場所をつくる

届いた感想を保存する場所をつくる

公開作品のフォルダをつくる

それぞれに正しいアクセス権を設定する

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

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

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

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

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

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

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

名前は、

DSC Builder

です。

たとえば、

「DSC0007番の会員を準備して」

とGPTに伝える。

すると、

必要なフォルダをつくる

権限を設定する

本当にその通りになったか確認する

ところまで支援する。

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

3.最初は、大きくつくりすぎた

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

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

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

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

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

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

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

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

技術的につくれるか。

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

今、それをつくる意味があるのか。

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

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

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

そして設計に、

「作れるものをすべて作る」のではなく、
「効果が確認できた部分だけ次へ進める」

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

実際に試す。

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

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

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

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

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

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

4.本当にコードができた

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

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

今回、コードそのものは全面的にAIに書いてもらいました。

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

私が行ったのは、

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

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

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

それまでも、

「AIはコードを書ける」

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

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

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

5.AIが、ユニットテストまで実行した

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

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

そして、

そのユニットテストを実際に実行しました。
コードを書く

ユニットテストを書く

ユニットテストを実行する

結果を確認する

問題があればコードを直す

またテストする

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

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

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

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

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

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

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

自分が必要としているシステムのコードが目の前で生まれ、
そのコードに対するユニットテストまで実行されていく。

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

6.ものを作る時間の流れが変わった

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

要件を考える

設計する

コードを書く

テストコードを書く

テストする

問題を調べる

コードを直す

またテストする

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

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

違ったのは、

その工程を回す速度です。

私が、

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

と問いかける。

AIが設計を確認する。

コードを書く。

テストを書く。

テストを実行する。

必要なら修正する。

そして、また次へ進む。

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

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

私は、

「便利になった」

とか、

「少し速くなった」

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

ものを作るときの、時間の流れそのものが変わった。

そう感じました。

7.AIは、模擬SharePointまでPythonでつくった

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

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

AIは、テスト用の模擬SharePointをPythonコードとして書いていました。

たとえば、

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

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

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

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

つまりAIは、

実際に使うコードを書く

そのコードを試すための模擬SharePointをPythonでつくる

ユニットテストを書く

ユニットテストを実行する

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

私はここでも、

AIはコードを書くだけではない

と感じました。

コードをつくる。

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

そしてテストする。

だからこそ、

書く

試す

直す

また試す

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

8.ところが、本物のSharePointでは違った

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

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

最初のコードでは、

「Full Control」

「Edit」

「Read」

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

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

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

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

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

理由は単純でした。

実際に動くプログラムも、テスト用の模擬SharePointも、
「権限の名前は英語で返ってくる」という同じ前提でつくられていたからです。

プログラムは、

「Full Control」

を使おうとする。

模擬SharePointも、

「Full Control」

を返す。

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

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

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

そこで初めて、

「英語の名前で返ってくる」という前提そのものが、
現実とは違っていた

ことが分かりました。

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

ユニットテストは、

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

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

ただし、

その想定そのものが現実と違っている場合は、
本物の環境で動かしてみなければ気づけないことがある。

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

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

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

模擬SharePointで試す

本物で動かす

現実との違いが見つかる

結果をAIへ返す

AIがコードを直す

テストも直す

また試す

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

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

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

10.「やり直す」ことにも問題があった

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

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

その後で処理が止まる。

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

そこで、

どこまで処理が進んでいたのかを確認する

安全に再開できる状態か判断する

再開できる場合は、その続きから進める

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

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

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

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

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

AIが原因を調べます。

コードを直します。

私はまた実行します。

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

11.AIがつくり、人間が現実に当てる

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

前回は、

人間が目的を示す

AIが設計案を出す

AIがレビューする

人間が判断する

設計を直す

という関係でした。

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

人間が目的を示す

AIと設計する

AIがコードを書く

AIが模擬SharePointをPythonでつくる

AIがユニットテストを書く

AIがユニットテストを実行する

人間が本物の環境で動かす

現実との違いを見つける

結果をAIへ返す

AIがコードとテストを直す

もう一度、本物で試す

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

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

AIがつくり、人間が現実に当て、その結果をまたAIへ返す。

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

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

前回の記事で、私は、

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

と書きました。

人間のチームで、

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

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

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

でもAIとの対話なら、

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

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

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

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

「この場合は?」

と聞く。

AIが直す。

テストする。

もう一度直す。

つまりAIは、

「もう一度、つくり直してみよう」

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

作る

試す

失敗する

直す

もう一度試す

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

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

13.文明の夜明けに立ち会っている

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

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

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

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

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

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

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

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

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

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

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

だから私は、本気で、

文明の夜明けに立ち会っている。

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

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

人間がものをつくる方法そのものが、変わり始めている。

私はそう感じました。

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

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

それでも、

何をつくりたいかを考える

AIと設計する

AIがコードを書く

AIがテストする

自分が本物の環境で動かす

違いを見つける

AIへ返す

また直す

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

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

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

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

むしろ、

AIが猛烈な速度でコードとテストをつくれる時代だからこそ、
現実に当て、違いを見つける人間の役割が、よりはっきり見えてきた。

そう感じています。

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

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

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

作る

使う

気づく

改善する

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

AIと一緒につくる。

現実に当てる。

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

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

第2章は、まだ始まったばかりです。

今回の開発で作成した主な設計・実装

  • Digital Supporters Club Phase 0 SharePoint / Teams ゲスト版プロトタイプ設計
  • DSC Builder GPT v0.1 ツール設計
  • Azure / Microsoft Entra ID 構築設計
  • DSC Builder API / Azure Functionsの実装コード
  • SharePointを模擬するPythonテストコード
  • DSC Builderのユニットテスト

今回のDSC Builderでは、 最初からすべてを自動化するのではなく、 まず新規会員のSharePoint利用開始準備に範囲を絞り、 実際にどの程度運営を楽にできるのかを確かめるところから始めました。

そして、この開発を通して、 AIがコードを書き、テストし、 人間が現実の環境で確かめ、その結果をまたAIへ返す という新しい開発の循環を体験することになりました。

Digital Supporters Clubの第2章は、 まだ始まったばかりです。

1 2 3 4 5 6 7 8 9 10 ...