【第5回】Claude がマンガを作る——「よくある技術」で AI にアプリを操作させた話

もっと任せたかった

前回、manginus という自作マンガエディタで第2話を完成させた。すべての操作に API があって、Claude Code から curl 感覚でマンガを作れる。

便利だった。間違いなく便利だった。

でも使い込むうちに、「もっと Claude に任せられないか？」という欲が出てきた。コマを追加して、画像を生成して、セリフを配置して、吹き出しのサイズを直して——ひとつひとつの操作は API で叩けるけど、それを指示するのは結局私だ。「全部やっておいて」と言いたい。

そこで manginus を「Claude が自律的にマンガを作れるシステム」へと進化させることにした。

使った技術は、どれも「みんな知ってるもの」だった。

枯れた技術の水平思考

manginus の進化に使ったのは、次の4つの技術だ。

• REST API
• React + Store 状態管理
• ロギング
• Pydoc（ドキュメント自動生成）

どれもエンジニアなら「ああ、あれね」と思うものばかりだ。新しい技術は何もない。

でも「AI にアプリを操作させる」という文脈に置くと、これらの技術がまったく違う意味を持ち始める。

REST API — AI が叩く「注文窓口」

そもそも API って何？

API は「注文窓口」のようなものだ。

レストランを想像してほしい。メニュー通りに「カレーください」と頼めば、厨房で調理されてカレーが出てくる。厨房の中で何が起きているかは知らなくていい。メニューに載っている注文の仕方さえ守れば、誰でも料理を受け取れる。

ソフトウェアの API も同じだ。「このデータをください」「この操作をしてください」と決められた形式でリクエストすれば、結果が返ってくる。内部の実装を知る必要はない。

REST API は、この注文窓口をウェブの仕組み（HTTP）で提供する方式のこと。ブラウザでURLを開くのと同じ仕組みで、プログラムからデータをやり取りできる。

従来の使われ方

普通、API を叩くのは人間か、フロントエンド（画面側のプログラム）だ。ボタンを押すと裏でAPIが呼ばれて、画面が更新される。あなたが普段使っているウェブサービスも、裏ではこの仕組みで動いている。

manginus での使われ方

manginus では、Claude が API を叩く。

ページ作成、コマ配置、画像生成、セリフ挿入、吹き出し調整。すべての操作がAPIとして用意されている。Claude はこの「注文窓口」に次々とリクエストを送って、マンガを組み上げていく。

レストランの比喩でいえば、今まで人間が注文していたところに、AI が座って注文している。メニューは同じ。注文の仕方も同じ。ただ注文する主体が変わっただけだ。

でも、これだけでは足りなかった。

React + Store 状態管理 — AI が UI を操作するための設計

Store って何？

まず「状態管理」という概念から説明する。

アプリには「状態」がある。「どのタブが選択されているか」「メニューは開いているか閉じているか」「どのオブジェクトが選択されているか」。こういった情報だ。

Store は、この状態を一箇所にまとめて管理する仕組みのこと。React というフロントエンドの技術と組み合わせて使うと、状態が変わったときに画面が安全に、予測可能な形で更新される。一方通行のデータの流れ（一方向データフロー）で動くから、「この操作をしたらこう変わる」が明確にわかる。

普通はこんな設計にしない

manginus のデータ——マンガのストーリー、ページ、コマ、画像、セリフ——を API で操作できるようにする。ここまでは普通の設計だ。

でも私は、さらに踏み込んだ判断をした。

UI の状態もサーバー側の Store で管理する。

普通、UI の状態はブラウザの中だけで管理する。サーバーが知る必要はない。

manginus では、UI のコンポーネント構造を3つの層に分けて設計し、それぞれの状態をサーバーの Store に載せた。

• Scene — アプリの大きな画面単位（編集シーン、プレビューシーンなど）
• Pane — シーンの中の領域。たとえば編集シーンなら左にページ一覧、中央にプレビュー、右にオブジェクトツリーといった分割
• Component — パネルの中の個別の部品

こうすると、UI のどの部品がどんな状態にあるかが、すべてサーバー側で把握できる。

なぜそうしたのか

データだけ操作できても、Claude は UI の構造がわからない。

たとえば「編集画面のページ一覧パネルを開いて、3ページ目を選択して」という操作。データ上の3ページ目にアクセスするだけなら API で十分だが、UI のどのパネルを開いてどの要素を選択するかは、UI の状態を知らなければ指示できない。

UI 状態をサーバーの Store に載せることで、Claude は API 経由で UI の構造と状態を把握できる。「このシーンに切り替えて」「このパネルを開いて」「この要素を選択して」と、コンポーネントの階層に沿って UI を操作できるようになる。

一方向データフローだから安全だ。Claude が Store の状態を変更すれば、React が画面を自動的に更新する。人間が操作したのと同じ結果になる。

ロギング — AI が「巻き戻す」ための記録

ロギングとは

ロギングとは「操作の記録」だ。

日記をつけるのと同じだ。「何時に何をした」を時系列で書き残す。ソフトウェアでは「いつ、誰が、何の操作をして、結果はどうなったか」をファイルに記録する。

普通、ログはデバッグ（バグ探し）や監査（「誰がいつ何をした」の記録）に使う。問題が起きたときに「何が原因か」を調べるための証拠だ。

manginus での使われ方

manginus では、FastAPI（サーバー）が全操作のログを記録している。

このログを Claude が読める。

すると何が起きるか。「さっきの操作を元に戻して」と言ったとき、Claude はログを遡って「直前の操作はコマ3の吹き出しを右に20px移動」と特定し、逆操作（左に20px移動）を実行する。

普通の「元に戻す」機能（undo）は、プログラムが操作の逆を記憶しておく必要がある。実装が大変だし、「3つ前に戻して、でも2つ前の変更は残して」みたいな柔軟な巻き戻しはできない。

ログベースなら、Claude が記録を読んで判断するから、どんな粒度でも巻き戻せる。「5分前の状態に戻して」も「このページだけ最初からやり直して」も対応できる。

安全面の配慮

ただし、ログを AI に全公開するだけでは危険だ。エラーが発生したとき、スタックトレース（エラーの詳細情報）に API キーやパスワードなどの機密情報が混入することがある。

manginus ではロギングにマスキング処理を入れている。機密情報がログに露出しないよう、特定のパターン（APIキー、トークンなど）を自動で伏せ字にする。

便利にするだけでは足りない。安全に使えるようにすることも同じくらい大事だ。

Pydoc — AI が「自分で学ぶ」教材

Pydoc とは

Python には「docstring」という仕組みがある。関数やクラスの直下に説明文を書いておくと、それがそのままドキュメントになる。

def create_page(story_id: str, title: str):
    """新しいページを作成する。
 
    story_id: ストーリーID
    title: ページタイトル
    """

Pydoc は、この docstring を自動的に整形して公開する仕組みだ。コードに書いた説明がそのまま「取扱説明書」になる。

manginus での使われ方

manginus では、すべての API の docstring を Help API として公開している。Claude がこの Help API を叩くと、「どんな API があるか」「各 API にはどんなパラメータが必要か」「戻り値は何か」が全部わかる。

つまり Claude は、自分で説明書を読んで、使い方を理解して、リクエストを組み立てる。

新しい API を manginus に追加したとき、私が Claude に使い方を教える必要はない。docstring を書いておけば、Claude が Help API を読んで勝手に使い始める。

人間の開発者向けに書くドキュメントが、そのまま AI の自己学習教材になる。

4つを並べてみると

ここまでの4つの技術を整理する。

どれも新しい技術ではない。REST API もStore も、ロギングもドキュメント自動生成も、何十年も前からある。

でも「AI がアプリを操作する」という視点で組み合わせると、それぞれが全く違う役割を果たす。

パイプラインのエージェント化

4つの仕組みが揃って、Claude は manginus を自律操作できるようになった。

しかし問題があった。

Claude Code は API を呼ぶたびに確認を求めてくる。「この API を呼びますか？ [y/n]」——マンガ1ページを作るのに何十回も API を叩く。そのたびに y を押す。

y 連打。

セットアップで y。画像生成で y。吹き出し配置で y。サイズ調整で y。エクスポートで y。

……本末転倒だ。「全部やっておいて」と言いたくて自動化したのに、y を押す作業が増えただけだった。

そこでパイプライン全体を manga-producer というエージェントにまとめた。ネームのデータを渡したら、あとは一気通貫で完成まで走る。

1. セットアップ — プロジェクト作成、キャラクター登録、ネーム読み込み
2. 画像生成 — 全コマの画像を ComfyUI で一括生成
3. 吹き出し調整 — セリフの文字数に応じたサイズ自動計算、位置調整
4. エクスポート — 全ページを高解像度 PNG で書き出し

y を押す必要はない。ネームを渡したら、コーヒーを淹れて待っていればいい。

浮かれていた

完全自動化だ。

ネーム会議で最善のシナリオが決まる。manginus にネームを渡せば、マンガが出来上がる。人間は「どれがいいか選ぶ」だけ。

ツール側は完璧だ——そう思っていた。

REST API で操作できる。Store で画面を共有できる。ログで巻き戻せる。ドキュメントで自己学習できる。パイプラインで一気通貫。

「あとはいい話を入れるだけだ」と浮かれていた。

……しかし「いい話を作る」こと自体が、とんでもなく難しかった。

次回予告

ツールの自動化はいくらでも進められる。API を生やして、パイプラインを組んで、エージェントに任せて。技術的な課題は、技術で解決できる。

でもマンガには「話作り」という、技術だけでは解決できない壁がある。

セリフを削ったら話が飛ぶ。話を繋げたら薄くなる。薄いからページを増やしたら、今度は構成が崩れる。

次回「話作りの壁」に続く。