あのツールは、
何でできていたのか

あのツールの正体は「テキストファイル数枚」

🍓いちごの種カウンターの中身を、フォルダごと開いてみます。すごい量のファイルがあると思うかもしれませんが、実物はこれで全部です。

seed-counter-worker/
├── wrangler.toml       ← 設定（どこで・どう動かすか）
├── src/
│   └── index.js        ← 本体のコード（受付の手順書）
├── public/
│   └── index.html       ← 画面（ブラウザに表示されるページ）
└── README.md            ← 人間向けの説明書

プログラムとは、コンピュータ向けに書いた手順書です。クリニカルパスが「この患者にはこの順番でこの処置をする」と書いてあるのと同じで、コードには「この入力が来たらこう確認し、こう転送し、こう返す」と書いてあるだけ。中身はただのテキストなので、専用ソフトがなくてもメモ帳で開けます（開いて眺めるだけなら壊れません）。

拡張子＝ファイルの種類の目印

ファイル名の末尾の .js や .py を拡張子と呼びます。カルテの「〇〇科」の表示のようなもので、中身の性格が一目でわかります。

試しに src/index.js の頭の方だけ、日本語の注釈付きで覗いてみます。英語に見えますが、読めなくて構いません。「ここは設定」「ここは指示文（AIへの日本語）」「ここは事務処理」の3種類に色分けできれば、今日は十分です。

const MODEL = "claude-opus-5";使うAIモデルの名前を指定している（設定）
const PROMPT = [
  "この画像に写っているいちごの表面の種(...)を数えてください。",AIへの指示文の書き出し。ここだけ日本語で読める
function json(status, obj) {
  return new Response(JSON.stringify(obj), ...);結果を決まった形（JSON）に整えて送り返す事務処理

つまり index.js は「設定・日本語の指示文・事務処理」の3つが順番に積み重なった手順書です。神経節細胞チェッカーを作ったとき、書き換えたのは主に指示文と「返事の書式」でした（第2回の「同じ体・違う指示文」の話）。

そのまま動くか、翻訳がいるか

第1回、Python版のツールを動かすときに ./.venv/bin/python server.py という呪文を打ちました。なぜ単一ファイル版の「いちごの種カウンター.html」はダブルクリックで開くだけで動き、server.py はこの呪文が要ったのか。ここに「実行環境」の正体があります。

同時通訳 vs 事前翻訳

Python や JavaScript のようなコードは、スクリプト言語と呼ばれます。書いた原稿（コード）を、その場で1行ずつ同時通訳する係が必要で、この通訳者のことをランタイム（実行環境）と呼びます。Python のコードには Python の通訳者が、JavaScript のコードには JavaScript の通訳者が要ります。

一方、Swift や C のような言語は、あらかじめ全部を翻訳して製本した本（実行ファイル）を作ってから配ります。これをコンパイル型と呼びます。iPhone のアプリや Word 本体がこちら側です。第1回で作った3つのツールは、全部スクリプト言語（Python / JavaScript）でした。

./.venv/bin/python は「今回だけ使う Python の通訳者」を名指ししていました。だからブラウザの JavaScript は何もインストールせず動いたのに、Python は事前に「通訳者を雇う」作業（インストール）が要ったのです。ブラウザには JavaScript の通訳者が最初から住み着いている ── これは第3章の伏線になります。

ライブラリ＝既製の部品

server.py の中身をよく見ると、自分では1行も書いていない「画像をAIに送る」処理を、たった数行で呼び出しています。これは anthropic というライブラリ（既製部品）を使っているからです。AIが書くコードの大半は、実はこうした既製部品の呼び出しでできています。院内製剤を一から作るのではなく、市販薬を処方箋どおりに組み合わせるイメージです。

requirements.txt の中身:
  anthropic>=0.121.0   ← 「anthropic という部品を使う」という発注書

package.json（第1回で作ったフォルダ直下）:
  { "devDependencies": { "wrangler": "^4.120.1" } }  ← 同じ発想のJS版
node_modules/          ← npm install で届いた部品の実物。27個の部品箱が並ぶ

pip install -r requirements.txt は、この発注書どおりに部品を取り寄せる作業です。届いた部品は .venv というこの道具専用の薬品棚にしまわれます。他のツール用に入れた部品と混ざらないようにするための仕切りです。

登場人物：クライアントとサーバー

第2回の資料で「登場人物は3人だけ」という図を見ました。スマホ＝クライアント（頼む側）、受付＝サーバー（頼まれて働く側）、AI本体という並びです。今回はこの「クライアント／サーバー」という呼び方そのものに焦点を当て、第1回の3つのツールを並べて比較します。

ここで重要な気づきがひとつ。ブラウザは「Webページを見る道具」であると同時に「JavaScriptを実行する環境」でもあります。単一HTML版がその証拠で、サーバーを一切使わずに、ブラウザの中だけで「写真を読み込む→AIに送る→結果を表示する」を全部やっていました。第2章で触れた「ブラウザにはJavaScriptの通訳者が最初から住み着いている」の意味が、ここで実物としてつながります。

CLIとGUI ── 命令の打ち方が2種類ある

第1回、黒い画面（ターミナル）に ./.venv/bin/python server.py や npx wrangler deploy と打ちました。これはCLI（コマンドライン）という操作方法です。普段使っているアイコンをクリックする方式はGUI（画面操作）と呼びます。

黒い画面は怖く見えますが、正体は「打った文字がそのまま命令になる」だけの仕組みです。詳しい使い方は第4回で扱うので、今日は「オーダー用紙の一種」という位置づけだけ覚えておいてください（補足はAppendix A）。

API＝書式の決まった依頼書と返書

第2回で「写真を送ってから答えが返るまでの6ステップ」を見ました。復習すると、受付（サーバー）が Anthropic のAPIに「写真＋指示文＋鍵」を送り、AIが「決まった書式（JSON）」で答えを返す、という流れでした。今日はその「決まった書式」の中身を実際に見ます。

index.js の中の依頼書は、ざっくり4項目でできています。「モデル名」（どのAIに頼むか）、「指示文」（何をしてほしいか、日本語）、「画像」（送る材料）、「返事の書式」（どんな項目でどんな順で答えてほしいか）です。第1章で見た PROMPT の変数がこの2つめ、SCHEMA という変数が4つめにあたります。

では実際に返ってきた答え（初見）を見てみましょう。

{
  "strawberry_found": true,いちごが写っていたか（真/偽）
  "seed_count": 212,数えた種の数（名前と値のペア）
  "confidence": "medium",AI自身の確信度
  "notes": "画像左のいちご1個を数えました。右下は..."補足コメント
}

波括弧 { } の中に「名前: 値」のペアが並んでいる ── これが JSON（ジェイソン）という書式です。プログラムが読みやすいように統一された書き方で、この形で受け取れれば、受付プログラムは「seed_count の値を画面に表示する」という機械的な処理だけで済みます。この書式は第6章でもう一度出てきます。

URLの読み方

デプロイ済みの URL https://ichigo-seed-counter.seed-counter-worker.workers.dev/api/count を分解してみます。

Python版で使った 127.0.0.1:8000 は、ホスト名の代わりに「自分のPC自身」を指す特別な住所（127.0.0.1）と、「8000番の窓口」というポート番号の組み合わせでした。どちらも「どの建物の、どの窓口か」という考え方は共通です。

どこで動かすか：ローカル vs クラウド

図1で見たとおり、受付（サーバー）の置き場所には「自分のPC」と「クラウド」の2択がありました。ここを詳しく見ます。

「手元で作ったコードを、外注先に預けて、そこで動いてもらう」ことをデプロイと呼びます。第1回、フォルダの中で npx wrangler deploy と1行打っただけで、seed-counter が workers.dev の URL を持つようになりました。あれがデプロイです。手順書（コード）そのものを Cloudflare の建物の中に置いてきた、というのが実際に起きたことです。

鍵の置き場については、ローカルでは export ANTHROPIC_API_KEY=...（そのコマンドを打った端末だけが覚えている「環境変数」）、クラウドでは npx wrangler secret put ANTHROPIC_API_KEY（Cloudflare 側の金庫＝シークレット）を使いました。どちらもコードの中に直接鍵を書かないという点は共通です。第2回の「受付に鍵を持たせる」の実装がこれでした。

有名な事業者

「仮想化」── 1台の機械を何十にも切り分ける

クラウドの安さの理由のひとつが仮想化です。データセンターにある巨大な1台の機械を、ソフトウェアの力で何十もの「仮想の小さなコンピュータ」に仕切って、別々のお客さんに貸し出しています。

シェアオフィスや大部屋を仕切りで区切るのと同じ発想です。だから「1台まるごと」ではなく「必要なぶんだけ」借りられ、使った分だけ支払えばよい。Cloudflare Workers は、この仮想化をさらに進めて「関数ひとつぶん」という極小の単位で貸し出す方式で、これが Cloudflare 側の費用が無料枠で収まった理由でもあります。

「ネットワーク」── URLを開いてから届くまで

あびこさんがスマホで URL を開いたとき、裏側では次のような経路をたどっています。

DNSは「ホスト名（〇〇.workers.dev）」を、機械が実際に使う住所であるIPアドレスに変換する電話帳のような仕組みです。そこからインターネットを経由して、実在するどこかの建物の中の機械に届きます。「クラウド」という言葉は雲のように実体がないものを連想させますが、実体は必ずどこかの建物の中の機械です。

データをどう残すか

第1回の3つのツールは、判定するだけで何も保存していません（毎回使い捨てです）。もし今後「結果を貯めたい」「表を読ませたい」となったら、次は保存形式の話が出てきます。合成データで、いちご3個の種の数を例に、同じ内容を3つの書き方で並べてみます。

① 平文（メモ帳の自由記載）

いちごA: 178個
いちごB: 205個
いちごC: 190個

② CSV ── Excelの表をテキストにしたもの

name,seed_count
いちごA,178
いちごB,205
いちごC,190カンマ(,)で区切って表を表現する

CSV は Excel でそのまま開けます。次回以降扱う「匿名化済み患者テーブル」も、この形式で扱う予定です。

③ JSON ── 第4章で見た「名前: 値」の入れ子

[
  {"name": "いちごA", "seed_count": 178},
  {"name": "いちごB", "seed_count": 205},
  {"name": "いちごC", "seed_count": 190}
]波括弧が入れ子になり、複数件をまとめて表現できる

JSON の前の世代には XML という書式もあります（<name>いちごA</name> のようにタグで囲む方式）。今はあまり新規には使われませんが、名前だけ知っておけば「ああ、あの仲間か」とわかります。

④ データベース ── 電子カルテの裏側

データの量が増え、複数人が同時に読み書きし、検索もしたくなると、テキストファイルでは追いつかなくなります。そこで登場するのがデータベースです。電子カルテの裏側で動いている仕組みも、ほぼ間違いなくデータベースです。

どちらが優れているという話ではなく、用途に応じた使い分けです。今日は名前だけ知っていれば十分です。

エラーは検査値

プログラムが赤い文字を出すと、多くの人はぎょっとします。しかし赤い文字は「故障」ではなく「検査値」です。機械が「どこで・何が」起きたかを、機械なりの言葉で報告しているだけ。読めなくてよく、正しい対応はそのままAIに貼ることです。第1回・第2回で実際に起きた（起きうる）代表例を3つ見てみます。

ModuleNotFoundError: No module named 'anthropic'既製部品(ライブラリ)が未インストール。requirements.txt の pip install をし忘れている
401 Unauthorized鍵(APIキー)か合言葉が違う。第2回の「金庫の鍵」の話に対応
Address already in use8000番の窓口が既に使用中。さっき起動した server.py を閉じ忘れている

ログとは、プログラムが「いつ・何をしたか」を記録した経過記録です。デバッグとは、症状（エラー）から原因を絞り込む作業 ── いわば鑑別診断です。AIに助けを求めるときのテンプレートは、実はカルテの書き方とほぼ同じ構造をしています。

まとめ：AIへの依頼文チェックリスト

問診が要件定義であるように、AIへの発注も「聞くべきことを聞き漏らさない」ことが質を決めます。今日出てきた語彙を、6項目のチェックリストにまとめました。

• 何を入れて何が出てほしいか（入力と出力）
• 誰が・どこで使うか（自分のPCだけ／スマホからも／他の人も）
• 結果を残すか（残すなら CSV か、表か）
• 外部サービス（API）を使うか・お金がかかるか
• 秘密情報（APIキー・合言葉）があるか、どこに置くか
• 患者情報は入れない（合成データで作る）

この6項目で、実際の「いちごの種カウンター」の依頼文を書くとこうなります。

補足資料

A. CLI（黒い画面）の基本コマンド

第1回で打ったコマンドの読み方だけ、ここにまとめておきます。詳しい操作は第4回で扱います。

B. git（元に戻せる保存履歴）

git は、コードの変更履歴を記録しておき、いつでも過去の状態に戻せる仕組みです。AIにコードを書き換えてもらって、もし壊れてしまっても、git があれば「さっきの状態に戻して」で済みます。詳しい使い方は第4回以降に扱いますが、「壊れても戻れる安心材料がある」とだけ覚えておいてください。

C. 用語ミニ辞典

暗記は不要です。今後の回で出てきたときに、ここに戻って引いてください。