AIエージェント入門 第十章!Claudeのアーティファクトで子供向け学習アプリを作ってみた

Claudeのアーティファクト、気になってたので試しにアプリを作ってみました。「ちょっとしたデモが作れる機能でしょ?」くらいの認識だったんですが、実際に触ってみたら想像以上に本格的なものが作れて驚きました。この記事では、作ったものの紹介と、開発中に見つけた技術的な気づきを共有します。

作ったもの

子供の国語力を鍛えるための学習アプリを作りました。毎朝10〜20分で1セッション完了する想定で、メニュー画面から4つの機能を選んで使う構成です。


読解トレーニング — AIが文章を生成し、選択式の理解チェック2問+記述式の要約問題1問+事実統合問題(表の読み取り)を出題します。回答するとAIがフィードバックを返してくれます。物語文と説明文の比率を変えながら、フェーズ1〜4で段階的に難易度が上がる設計です。

漢字クイズ — 学年別の配当漢字から出題される4択クイズ。「よみ→かんじ」「いみ」「あてはめ」の3タイプをランダムに混ぜて5問出題します。正解履歴を追跡して、まだ正解していない漢字を優先的に出題する仕組みも入れました。

写真で解説 — 問題の写真を撮ると、AIがストリーミングで解説してくれる機能。複数枚対応、画像の回転・トリミング、max_tokens到達時の自動再接続(最大3回)まで実装しています。

漢字スキャナー — 写真から漢字を認識して、読み方・書き順・部首・使い方を調べられる機能。文字抽出→詳細解析の2段階API呼び出しで、書き順はオープンソースのSVGデータを使って表示しています。

全部1ファイルのReactコンポーネントで、コードは約800行くらいです。

アーキテクチャ

このアプリの面白いところは、アーティファクトの中からAnthropic Messages APIを直接叩いている点です。アーティファクトにはwindow.claude.complete()というビルトインのAPIがあるんですが、今回はあえてfetchでMessages APIを直接呼んでいます。理由は、ストリーミング対応やMCP連携など、より細かい制御が必要だったからです。

参考リンク

システム構成図


モデルの使い分け

用途に応じてClaudeの3モデルを使い分けています。

問題生成(読解・事実統合)にはOpus。文章の質やバリエーション、指示の遵守度が高いので、ここはコストをかけてでもOpusを使う価値があります。問題生成(漢字クイズ)と回答評価にはSonnet。十分な品質でOpusより速くて安いです。Notion保存や文字抽出のようなシンプルなタスクにはHaiku。速度とコスト重視の処理に割り当てています。

機能ごとの処理フロー

各機能がどのようにAPIを呼び出しているか、シーケンス図で示します。

1. 読解トレーニング


2. 漢字クイズ


3. 写真で解説

アップロード中: 83319 / 83319 バイトをアップロードしました。

4. 漢字スキャナー



気づき①: window.storage

アーティファクトでアプリを作るとき、最初にぶつかる壁が「データの永続化」です。アーティファクトはサンドボックス化されたiframe内で動くので、localStoragesessionStorageは使えません。

その代わりに用意されているのがwindow.storageです。キーバリュー型のストレージで、以下のAPIが使えます。

// 保存
await window.storage.set("key", "value");

// 取得({ value: "..." } が返る)
const result = await window.storage.get("key");

// 削除
await window.storage.delete("key");

// プレフィックスでキー一覧
await window.storage.list("prefix:");

(仕様をちゃんと確認したわけじゃないのですが)同一チャット+同一ファイル名であればデバイス間で共有されます。今回のアプリだとPCで進めた学習の進捗がスマホで開いても引き継がれます。容量は1アーティファクトあたり最大20MBで、Pro・Max・Team・Enterpriseプランで利用可能です。

今回のアプリでは、学習の進捗データ(累計クリア回数、連続日数、出題履歴)や漢字の正解履歴のキャッシュに使っています。Notionを永続ストアとして併用しつつ、window.storageを一次キャッシュにすることで、起動時の読み込みを高速化しています。

注意:公開していないとstorageは使えない?

公式ドキュメントには「Persistent storage is only available for published artifacts. During development and testing, storage operations will not succeed until the artifact is published.」と明記されています。アーティファクトを公開(Publish)しないとstorageは動作しないようです。また、公開を取り消す(Unpublish)と保存データが完全に削除されるとも書かれています。

ただ、今回の開発中に確認した限りでは、公開していない状態でもチャット内でアーティファクトを実行すればstorageの読み書きは正常に動作していました。セッションをまたいでもデータは保持されていたので、「開発中は動かない」という記載とは矛盾する挙動です。

この辺りの仕様は変更される可能性もあるので、安定して使いたい場合はアーティファクトを公開した状態で利用するのが確実です。

参考リンク

気づき②: アーティファクトからMCPを使うお作法

学習の回答履歴をNotionに保存したかったので、アーティファクトからNotion MCPを呼ぶ方法を模索しました。結論から言うと、Anthropic Messages APIのmcp_serversパラメータを使います。

仕組み

アーティファクトの中から直接MCPサーバーを叩くことはできません。代わりに、Messages APIにリクエストを送る際にmcp_serversパラメータでMCPサーバーのURLを指定すると、Claude(APIのモデル)がMCPツールを使ってくれます。

アーティファクト (fetch)
  → Anthropic Messages API + mcp_servers パラメータ
    → Claude (Haiku) がNotion MCPのツールを呼び出し
      → Notionにデータ保存

具体的なコードはこんな感じです。

const res = await fetch("https://api.anthropic.com/v1/messages", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    model: "claude-haiku-4-5-20251001",
    max_tokens: 4096,
    system: "Call notion-create-pages tool ONCE with the JSON the user gives you. No questions, no explanations.",
    messages: [{ role: "user", content: JSON.stringify(toolInput) }],
    mcp_servers: [{
      type: "url",
      url: "https://mcp.notion.com/mcp",
      name: "notion"
    }]
  })
});

ポイントは、Haikuをルーターモデルとして使っている点です。systemプロンプトで「渡されたJSONでNotionのcreate-pagesツールを即座に呼べ」と指示するだけ。Haikuは安くて速いので、「MCPツールを呼ぶためだけの中継役」として最適です。保存は非同期(fire-and-forget)にして、UIをブロックしないようにしています。

環境ごとの制約

開発中にハマったのが、アーティファクトの実行環境によってMCP連携の挙動が変わる点です。

Claudeのチャット画面でアーティファクトを作成・実行した場合は、上記の方法でNotion保存が正常に動作します。一方、左メニューの「アーティファクト」セクションから開いた場合や、Coworkのチャット内でアーティファクトを作成した場合は、同じコードでもNotion保存が失敗します。

原因の詳細は不明ですが、アーティファクトの実行環境の違い(ネットワークやサンドボックスの設定差)に起因するものと推測しています。開発時はチャット内でアーティファクトを作成するのが無難です。

参考リンク

気づき③: Claudeはアーティファクトについてあまり知らない

アーティファクト開発で一番苦労したのは、Claude自身がアーティファクトの仕様をあまり把握していません。公式ドキュメントに書いてない事も多いです。

window.storageのAPIや制約について聞いても正確な回答が返ってこないことがあり、結局は自分で動かして確認する必要がありました。

公式ドキュメントについても、記載されていない仕様がそれなりにあります。例えば、設定画面には「AI搭載のアーティファクト」という独立したトグルが存在しますが、この設定が何を制御しているのかドキュメントには説明がありません。また、前述のwindow.storageの「公開しないと動かない」という記載と実際の挙動の食い違いや、実行環境によるMCP連携の挙動差についても、ドキュメントからは読み取れません。

つまり、アーティファクトで本格的なアプリを作ろうとすると、「ドキュメントを読む→Claudeに聞く→自分で試す」のサイクルのうち、最後の「自分で試す」の比重がかなり大きくなります。まだ新しい機能ということもあり、トライ&エラーで仕様を確認していく事が必要そうです。

まとめ

「アーティファクトってどんなもんだろう」くらいの軽い気持ちで試してみましたが、想像以上に使えそうなアプリが作れました。

特に良かった点は、AIによる問題生成+評価のパイプラインがアーティファクト内で完結すること、window.storageによるデバイス間データ共有、そしてMCP連携で外部サービス(Notion)とつながれることです。そしてそれが、ほぼコーディングする事なくできあがる事です!

一方で、実行環境によるMCP連携の挙動差や、AIが生成するコンテンツのバリデーションの必要性など、実際に作ってみないとわからない課題もありました。アーティファクトは「ちょっとしたデモ」にとどまらず、工夫次第でけっこう本格的なツールが作れるプラットフォームだと思いました。



このブログの人気の投稿

AIエージェント入門 第八章(前編)!Claude Codeを全社展開する前に管理者が押さえておきたい組織運用のポイント

リスクアセスメント

重要な情報(個人情報とか)の保管場所としてのGoogleドライブについて考えてみる