こんにちは、健ちゃんです。

僕は毎日AIで3Dモデルを開発していますが、ふと思い立って「BOOTHで無料配布しよう」となり、先日実際にやってみました！

そのときに配布形式でいろいろ悩んだので、僕の勉強も兼ねて違いを記事にまとめてみました。

VRM・FBX・Blenderは、次にする作業で選ぶ

AIで3Dキャラクターを作ったあと、VRM、FBX、Blenderという3つの形式を前にして止まったことはありませんか。

僕も「同じモデルなら、どれを選んでも大きくは変わらない」と思っていました。ところが、同じシャオランのモデルを3形式で開き直すと、持ち越せる情報がかなり違ったんです。

先に結論を言います。

• すぐにアバターとして使いたいなら、VRM

• Unityなどへ持ち込み、受け側で設定するなら、FBX

• 形、衣装、リグまで深く直したいなら、Blender作業ファイル

大事なのは、形式の人気ではなく「次に何をするか」で選ぶことですよ。

同じシャオランを3形式で再読込しました

比較したのは、一忍のメルマガ登録特典として配布しているシャオラン3Dモデル v1.0.0です。同じ配布zipに入ったxiaolan.vrm、fbx/xiaolan.fbx、xiaolan.blendを使いました。

Blender 5.1の初期状態から各ファイルを再読込し、オブジェクト、骨、表情、材質、揺れ設定を確認しました。

• VRM：28オブジェクト、8メッシュ、90 bones、13表情＋Basis、16 materials、11 springs・9 colliders

• FBX：8オブジェクト、7メッシュ、114 bones、14 shape keys、14 materials、VRM固有の揺れ設定なし

• Blender作業ファイル：35オブジェクト、17メッシュ、114 bones、47 shape keys、15 materials、制作時の揺れ設定を保持

これは数字が多いほど優秀、という比較ではありません。形式ごとに、次の作業へ持ち越す情報が違うんです。

VRMは、完成アバターをすぐ使う形式

VRMでは、Humanoid、表情、視線、MToon、SpringBoneなど、人型アバターとして扱うための機能が整理されています。

今回のVRMにも、54個のHumanoid bone、13個の実変位モーフ、11個のspring、9個のcolliderが入っていました。対応アプリが頭の骨、笑顔、髪の揺れを解釈しやすいため、配信やモーション確認でまず動かしたいときに向いています。

一方、Blenderへ読み戻した骨は90本で、作業ファイルの114本より少なくなりました。VRMは制作途中の構造へ戻る形式ではなく、完成アバターを使う形式なんです。

FBXは、別環境へ運んで仕上げる形式

FBXは、Blender、Unity、Unreal Engineなどの間で、骨とメッシュを受け渡すときに使われます。今回も、作業ファイルと同じ114 bonesを保持していました。

ただし、VRMのHumanoid割り当て、表情プリセット、MToon、SpringBoneが、そのままFBXの共通仕様になるわけではありません。

髪の揺れ、アバターの骨割り当て、材質の見え方は、到着先で設定し直す場合があります。FBXは全部入りの保存形式ではなく、別環境へ運んで仕上げる形式と考えると分かりやすいですよ。

Blender作業ファイルは、深く直すための正本

Blender作業ファイルには、完成モデルだけでなく、制作に使った構造も残っています。今回の.blendには、35 objects、17 meshes、114 bones、47 shape keys、15 materials、5 packed imagesがありました。

形を直す、衣装の貫通を直す、表情を足す、骨の位置を調整する。こうした作業では、Blenderファイルを正本にしたほうが戻りやすいんです。

ただし、.blendを開けば、そのまま配信アプリやゲームで使えるわけではありません。編集後は用途に合わせてVRMやFBXへ書き出し、設定を確かめます。

失いたくないものから逆算する

迷ったときは、次の場所で何をやり直したくないかを考えます。

1. 完成アバターを今すぐ動かしたいならVRM 2. ゲームエンジン側で作り込むならFBX 3. 形やリグそのものを編集するならBlender作業ファイル

複数の用途があるなら、Blender作業ファイルを制作の正本として残し、使う場所ごとにVRMとFBXを書き出す運用が安全です。

同じ3形式を、自分の環境で確かめられます

今回比較したシャオラン3Dモデル v1.0.0は、一忍のメルマガ登録特典として受け取れます。

VRM、FBX、Blender作業ファイルに加え、テクスチャとUV展開図を含む全28ファイルです。特典版は改変と商用利用が可能で、モデル本体、改変データ、変換データの再配布はできません。

シャオラン3Dモデルの3形式を受け取る

なお、今回比較したのはメルマガ特典版v1.0.0です。BOOTHで配布しているVRM版や、開発中の別リリースとは利用条件と内容が異なります。

まとめ

VRM、FBX、Blender作業ファイルは、同じ見た目を別の拡張子で保存したものではありません。

• VRMは、完成アバターをすぐ使う

• FBXは、別ソフトやゲームエンジンへ運んで仕上げる

• Blender作業ファイルは、形やリグまで深く直す

僕なら、編集できるBlender作業ファイルを正本として残し、使う場所に合わせてVRMとFBXを選びます。

形式を選ぶときは、「何が入っているか」だけでなく、「次の場所で何をやり直すか」まで見てくださいね！

参考資料

• Features and contents of VRM（VRM Consortium）

• VRM 1.0（VRM Consortium）

• FBX - Blender Manual

貧乏人の「社長室」運用方法。ClaudeでCodex部隊を統括！

こんにちは、健ちゃんです。

「社長室」とは、Claudeで社長室というセッションを立ち上げ、そこから複数のAI作業セッションを束ねる運用です。人間が各セッションを直接見て回らなくても、社長室の秘書役が指示と報告をまとめてくれます。いわゆるAIのオーケストレーションですね。

この社長室を作れば、ClaudeとCodexの複数セッションを1つの窓から動かせます。ただ、実際に1日回すと別の問題が出ました。便利になった分だけ仕事が並行し、秘書役のセッションも常時動くので、Claudeの利用枠が午前中だけで1日分近く減ってしまったんです。

資金がふんだんにあれば、Claudeの複数アカウントで運用すれば済む話です。でも、僕にはそんなお金はないので、AIの運用方法を工夫しないといけません。

そこで、Claudeを司令塔に残し、実働の大半をトークン効率の高いCodexへ移し、難しい仕事だけClaudeへ戻す形に変えました。この記事では、品質と費用を両立させる「貧乏人のための社長室」の組み方を紹介します。

1. 社長室を動かすと、仕事だけでなく利用枠の消費も加速する

社長室を作ると、僕が複数のチャットを巡回しなくても仕事が進みます。これは本当に楽でした。ただし、楽になったからこそ、同時に動かせる仕事の数も増えるんです。

僕が1日運用してみたときは、午前中だけで予定していた1日分近くのClaude利用枠を消費しました。社長室を置く前より多くの案件が並行したので、まず実働セッション側の消費が速くなったんですね。

もう1つは、秘書役によるトークン消費です。社長室も1つのClaudeセッションなので、各担当が使う利用枠とは別に、指示の整理、見回り、報告の受け渡しにも利用枠を使います。

つまり、社長室の消費が増える理由は2つあります。仕事をたくさん回せるようになったことと、その仕事を束ねる秘書が増えたことです。

だからといって、僕は社長室をやめたいとは思いませんでした。人間がすべての現場を巡回する形へ戻さず、AIの運用方法だけを変えればよいと考えたんです。

2. Claudeは社長室に残し、Codexを実働部隊にする

僕が選んだのは、Claudeを人間と話す社長室に残し、その下へ複数のCodexセッションを置く形です。人間はClaudeの窓だけを見て、継続作業はCodexの実働部隊へ任せます。

この構成なら、社長室が持つ「窓口を1つにする」という価値は失われません。一方で、すべての担当をClaudeでそろえる場合より、Claude側の利用枠を実働へ使い続けずに済みます。

Claude Codeから既存のCodexセッションへ指示を渡す入口として、現行のCodex CLIにはcodex queueがあります。対象セッションのIDか正確な名前を指定し、後続のメッセージを積めます。

codex queue --thread "<セッションIDまたは正確な名前>" \
  --message "次の作業へ進んでください。"

ただし、コマンドが終了コード0を返しただけでは、担当が作業を始めたとは限りません。僕は、指示がキューへ保存されたまま、担当が再開せずに止まった経験があります。

そこで、一覧、読取、確認付き送信をまとめたcodexsessという補助CLIを作りました。これはCodexの公式機能ではなく、Codex app-serverへ接続して使う僕の管理ツールです。

codexsessは、送信前に宛先と本文を表示し、確認後に指示を投入します。さらに「受付」「開始」「到達確認」を分け、送ったつもりを成功扱いしないようにしました。

内部ではCodex app-serverを使いますが、これは現行CLIでも実験的機能です。環境やバージョンで挙動が変わり得るため、利用前にcodex queue --helpとapp-serverの状態を確認してください。

3. 安い秘書は、忘れる前提で仕組みにする

では、社長室のClaudeも軽いモデルへ替えれば、すべて解決するのでしょうか。利用枠の消費は抑えやすくなりますが、僕の環境では別の問題が出ました。

秘書役をSonnetにして試したところ、フォーカスセッションの切り替えをよく忘れたんです。担当が動き始めても同じ案件を見続けたり、次に見るべき案件へ移らなかったりしました。

これは、Sonnetが必ず忘れるという一般論ではありません。僕がこの社長室とルールで運用したときの結果です。モデルを替えたときの消費量の差も、厳密な料金比較ではなく、僕の利用枠で見た感触にすぎません。

Sonnetが忘れやすいとはいえ、秘書を置かずに自分で全セッションを巡回するよりは楽でした。僕は忘れたと気づくたびに「フォーカスを切り替えて」と伝え、重要なルールはプロンプトと運用ファイルへ残しています。

安いモデルへ替えるなら、性能差を気合いで埋めるのではなく、忘れる前提で仕組みにする必要があります。移行条件を短く固定し、報告の形を決め、到達確認を機械に任せるんです。

ここで大切なのは、いちばん安いモデルへ全部を寄せることではありません。常時動く部分を軽くして、高い能力が必要な仕事だけ別の経路へ逃がすことです。

4. Codexでは難しい仕事だけ、Claude(Fable)へ戻す

Codexを実働部隊にすると、「文章やデザインの品質までCodexだけで足りるのか」と不安になりますよね。僕も、すべての仕事をCodexだけで終わらせるつもりはありません。

僕の考え方は、大半の調査、実装、検証をCodexへ任せ、Codexでは難しい一部分だけClaudeへ戻すというものです。この記事では、その難所だけを担当するClaudeを「Claude遊撃隊」と呼びます。

Claude Codeには、1回の指示を渡して結果を受け取る-pがあります。たとえば本文の文章化だけFableへ任せたいなら、Codex側から次のように呼び出せます。

claude --model claude-fable-5 -p "構成と素材に沿って本文を書いてください"

この経路は、ClaudeからCodexを動かし、さらにCodexからClaudeを呼ぶので、見た目はまどろっこしいです。でも、高性能モデルを全工程で使わず、効果が大きい難所へだけ投入できます。

僕の運用では大半をCodexへ任せられましたが、これはベンチマーク結果ではありません。あなたの仕事を試しながら、Codexで完結する範囲と、Claudeへ上げる条件を決めてください。

5. 「貧乏人の社長室」は、安いAIではなく高いAIの呼び場所を決める

貧乏人の社長室を始めるとき、最初に決めることは3つだけです。誰が人間と話すのか、誰が普段の実働を担うのか、どんな条件で高性能モデルへ上げるのかです。

• 司令塔：Claudeの社長室 — 優先順位、フォーカス、報告の形を決める

• 常用する実働：複数のCodexセッション — 案件ごとの継続作業と検証を担う

• 難所の遊撃隊：Claudeの高性能モデル — 文章、デザインなど呼び出す条件を決める

いきなり多くの案件で試す必要はありません。継続案件を3つ選び、「Codexで完結」「難所だけClaude」「最初から人間とClaude」の3つへ分類してみてください。

ここで、僕のClaude Max $200プランでの実測も出しておきます。約8時から15時までの7時間、社長室とFableのセッションを主に使ったところ、週間枠の消費は4%でした。

この4%にはFableの利用も含まれるため、社長室だけの数字ではありません。セッション別の推移から、社長室単独の消費はざっくり2%だったと見積もっています。

• $200プランで7時間、週間枠を4%消費：社長室とFableを主に使った実測

• 社長室単独で約2%：セッション別推移からの概算

• $100プランなら約8%相当：週間枠を4分の1相当として換算した類推

$100プランでの8%相当は、実際に測った数字ではありません。$100プランの週間枠を$200プランの4分の1相当として、同じ使い方をした場合へ単純換算した概算です。

週間枠を7日で均すと、1日分は約14%です。そのうち社長室だけで8%相当を使えば、ほかの作業へ残るのは6%相当という計算になります。

この計算が正しければ、Claude秘書は1ヶ月で5千円（Max $200プラン）から1万円（Max $100プラン）程度の費用がかかります。これを高いと見るか、安いと見るかはお任せします。

実測の証跡には、現在のセッション使用率と、週間制限における全モデル・Fableのみの推移を表示したスクリーンショット2枚を使いました。ただし、これらは僕の環境での実測と類推であり、一般的な消費量や公式の料金試算を示すものではありません。

*7時57分時点。現在のセッション6%、週間すべてのモデル27%、Fableのみ21%。*

*14時47分時点。現在のセッション15%、週間すべてのモデル31%、Fableのみ27%。*

使い始めたら、モデルごとの消費量だけでなく、人間が何回現場へ戻ったかも測ってください。同じ案件数で作業全体の利用枠が何割減るかは、まだ比較できていません。

利用枠の減りが遅くなっても、あなたの巡回や手直しが増えすぎるなら、その配置は成功ではありません。モデルの安さではなく、人間を含む運用全体で判断するんです。

逆に、AI側の処理が少し遠回りでも、人間が見る窓を1つに保ち、高性能モデルの出番を限定できたなら、社長室を続けやすくなります。僕が作りたかったのは、最安のAI組織ではなく、無理なく回し続けられるAI組織なんです。

今回紹介したcodexsessは、僕の環境で使っている補助CLIです。メルマガ登録者特典のスターターキットへ収録しているので、自分で一覧・読取・確認付き送信を組むところから始めたくない方は、そちらも判断材料にしてください。

社長室は便利で、僕はアリだと思っています。ただ、実際に利用枠を消費し、お金もかかる運用です。誰にでも勧めるのではなく、あなたのプラン、使う時間、任せる仕事を見ながら慎重に判断してください。

メルマガ

元エンジニアがAIについて、実践を元に発信しているメルマガです！ ぜひご登録ください。

メルマガに登録してスターターキットを受け取る

こんにちは、健ちゃんです。

AIにYouTubeのURLを渡したのに、要約が薄い。動画と違う内容が返る。結局、文字起こしをコピーして貼り直している。

そんな経験があるなら、原因はAIの要約力だけではないかもしれません。字幕だけを材料にした要約では、画面にしか出ていない情報を拾えないからです。

すべてのYouTube要約AIが字幕だけを使うわけではありません。今回は、36分22秒のBlender講座を、YouTube自動字幕と、音声・映像の両方を分析するvideo2mdで比べました。

結論は明確です。

• YouTube文字起こしは「何を話したか」を確認するもの

• video2mdは「何を話し、画面で何をしたか」を探すもの

video2mdは約74秒で、字幕にはない画面情報を46件抽出しました。

字幕では消えた「レベル1」が残った

対象にしたのは、ふさこさんの「Blenderでキャラクターモデル制作！01｜顔のモデリング（前編）」です。

ふさこさんの動画は、僕自身Blenderの勉強で、何度も拝見しています。ありがとうございます！

で、この動画の15分前後で、話者はモデルの表面を滑らかにするSubdivision Surfaceを追加します。

YouTube自動字幕に残ったのは、次の発話です。

> サブディビジョンサーフェイスを追加して見てみます。うん、今こんな感じですね。

機能を追加したことは分かります。しかし、設定値は分かりません。

同じ場面をvideo2mdで分析すると、こうなりました。

> [15:10] Add ModifierでSubdivision Surface（レベル1）を適用し、曲面状態を確認。

「レベル1」は話者が読み上げていません。Blenderの画面に表示されていた情報です。

字幕だけで要約すると「Subdivision Surfaceを追加した」で終わります。映像まで分析すると「レベル1で追加した」と、再現に必要な情報まで残せます。

36分の動画から、設定と操作を46件拾えた

video2mdはYouTube動画の音声と映像を分析し、概要、画面情報、整形した発話をMarkdownへまとめるCLIツールです。Markdownは、見出しと時刻が付いた検索しやすいテキストファイルです。

今回の結果は次の通りでした。

• 動画の長さ: 36分22秒

• 処理時間: 約74秒（1回の実測）

• 画面情報: 46件

• 整理された発話: 124区間

画面情報には、次の設定や操作が時刻順に残りました。

• 05:37　MeshからCircleを選び、頂点数を8にする

• 08:11　Mirrorモディファイアーを追加し、Clippingを有効にする

• 15:10　Subdivision Surfaceをレベル1で適用する

• 27:34　透視投影へ切り替え、焦点距離を80mmにする

• 30:28　Slide Relaxで頂点の偏りをならす

動画を最初から見直さなくても、Clippingや80mmで検索すれば、必要な場面へ絞り込めます。

出力MarkdownをAIへ渡す具体例

video2mdが作ったMarkdownは、そのままAIチャットへ添付できます。ファイル添付に対応していない場合は、「映像・画面の内容」の部分だけを貼り付けます。

たとえば、次のように頼みます。

添付したMarkdownの「映像・画面の内容」だけを使って、
Blenderの操作と設定値を時刻順に整理してください。

- 表の列は「時刻 / 操作 / 設定値」
- 推測は加えない
- 数値やON/OFFが書かれていない場合は「記載なし」と書く

今回のMarkdownをこの形式で整理すると、次の5件を取り出せます。

| 時刻 | 操作 | 設定値 | |---|---|---| | 05:37 | MeshからCircleを追加 | 頂点数8 | | 08:11 | Mirrorモディファイアーを追加 | Clippingを有効化 | | 15:10 | Subdivision Surfaceを適用 | レベル1 | | 27:34 | 透視投影へ切り替え | 焦点距離80mm | | 30:28 | Slide Relaxで頂点密度を均等化 | Shiftを押しながらストローク |

AIへ任せるのは、video2mdが拾った情報の並べ替えです。元のMarkdownにない手順を考えさせるわけではありません。

これで、36分の動画を見直す前に「どの設定が、何分ごろに出たか」を一覧にできます。ただし、video2mdの時刻は概算で、誤った補正もあります。実際に操作するときは、必要な場面だけ元動画で確認します。

YouTube文字起こしとの違い

video2mdは、YouTube文字起こしの高精度版ではありません。役割が違います。

| 知りたいこと | 適した方法 | |---|---| | 実際に何と話したか | YouTube文字起こし | | 発話の細かな時刻 | YouTube文字起こし | | 画面に出た設定や操作 | video2md | | 動画全体の流れと手順 | video2md |

発話だけで内容が伝わる対談やポッドキャストなら、YouTube文字起こしで十分です。

一方、ソフトウェア操作、スライド講義、ゲーム解説、制作工程のように、画面が情報の一部になっている動画では、文字起こしだけでは重要な部分が抜けます。

video2mdにも間違いはある

video2mdの出力を、そのまま正確な記録にはできません。生成AIが内容を読みやすく整えるため、誤った補正も入るからです。

今回、YouTube字幕では正しかった「終わりよければ全て良し」を、video2mdは「割りよければ全て良し」と変えていました。直前までメッシュの「割り」を説明していたため、文脈へ寄せすぎたと考えられます。

時刻も概算です。比較できた44区間では、YouTube字幕とのずれは中央値2.5秒、最大26.0秒でした。

そのため、直接引用、数値、ショートカット、正確な時刻は元動画で確認します。

実務では「探す」と「確認する」を分ける

僕なら次の順で使います。

1. video2mdで動画全体の流れ、操作、設定値を探す 2. 必要な場面だけ元動画を再生する 3. 引用と正確な時刻は、YouTube文字起こしと元動画で確認する

video2mdに「探す仕事」を任せ、人は見つかった場面だけ確認する。この分担なら、長い動画を全部見直す時間を減らしながら、AIの間違いもそのまま通さずに済みます。

まず1本で、画面情報が何件出るか試す

使用したツールはvideo2mdです。今回は次のように動画単体URLを指定しました。

python3 video2md.py \
  "https://www.youtube.com/watch?v=pk8POJpBkVs" \
  --lang ja \
  -o output

最初からすべての動画へ使う必要はありません。まず操作動画やスライド講義を1本だけ分析し、字幕になかった設定や手順が何件残るかを見てください。

発話だけで足りるならYouTube文字起こし。画面も必要ならvideo2md。この判断ができれば、YouTube要約ツールを次々に試す前に、何が足りないのかを切り分けられます。

---

※数値は2026年8月28日に1本の動画で取得した結果です。モデルやYouTube自動字幕の更新により、同じ動画でも結果が変わる可能性があります。

こんにちは、健ちゃんです。

突然ですが、先日の話から。僕の手元では8つの案件が同時に動いていました。動画、AI動画、3Dモデル、音楽ゲーム、TCG本体、TCG Web、攻略PDF、そして記事企画です。それなのに、僕が見ていたチャットは8つではなく、たった1つだったんです。さて、これはどうやったのでしょうか。

AIへ仕事を分けたのに、なぜか自分が楽にならない。もしあなたがそう感じているなら、原因は作業そのものではありません。巡回、報告の回収、「次にどのチャットを見るか」の判断が、あなたに残っているからなんです。

この記事では、その判断ごとAIへ渡す「社長室」という運用を、1日試して分かった限界まで含めてお話しします。

なお、この運用の原型はルクさんが公開してくれたものです。ルクさん、ありがとうございます！

AIを増やしたら、管理する僕のほうが忙しくなった

複数のAIセッションを走らせれば走らせるほど疲れる。あるあるですよね。でもその原因は、画面の数ではありません。「次にどれを見るか」を決める判断と、話題を切り替えるたびのコンテキストの入れ替えなんです。

僕も最初は、複数セッションを1画面へ並べて表示する機能を使っていました。一覧できると把握感が高まるので、一見よさそうに見えるんですね。

ところが実際にやってみると、結局は自分でいろいろなセッションを見に行ってしまいます。これは社長が自分の足で現場を巡回しているのと同じで、どこへ行くかを考えるだけであなたのエネルギーが減っていくんです。

つまり、AIを増やして楽になるためには、作業だけでなく「巡回と選択」もAIへ渡す必要があります。そのための窓口が今回の社長室です。

「社長室」は、使い捨てのサブエージェントではない

もしかしたらサブエージェントの話でしょう、と思った方がいるかもしれません。違うんです。

サブエージェントは、いま開いているセッションから立ち上げて、1つのタスクを渡し、終わったら消える使い捨ての存在です。一方、社長室が束ねるのは、履歴を持ってずっと働き続けている「継続セッション」たちなんですね。

僕の場合、社長室はローカルコマンドを実行できるClaude Codeデスクトップアプリへ置きました。そこからClaudeの継続セッションと、Codexの継続セッションの両方を、秘書役のAIにまとめて管理させています。

Claude CodeからCodexを動かす最小手順

意外だったのは、ClaudeからCodexの継続セッションへも指示を飛ばせたことです。最小構成なら、Codex CLI標準のcodex queueをClaude Codeから実行します。

必要なのは、Codex CLI、指示先となる既存セッションのUUIDまたは正確な名前、ローカルコマンドを実行できるClaude Codeの3つです。通常のClaudeチャットから、コマンドを貼るだけでは動きません。

まずClaude Codeのターミナルで、queueが使える版かを確認します。そのうえで、対象と本文を表示して確認し、既存セッションへ指示を積みます。

codex queue --help
codex queue --thread "<セッションUUIDまたは正確な名前>" \
  --message "そのまま記事制作を進めてください。"

送ったらCodexの画面で対象セッションを開き、送信文が利用者メッセージとして追加されたことを目で確認します。CLIが成功を返しただけで、到達確認を終えないのがポイントです。

補助CLI codexsessは僕専用の未配布ツール

僕は見回りと誤送信防止のために、~/bin/codexsessという1ファイルの補助CLIも使っています。これはCodexの標準機能でも公開済みツールでもなく、今回の運用用に用意したものです。

codexsess list --since 180 --json
codexsess read <thread-id> --full
codexsess send <thread-id> "そのまま記事制作を進めてください。"
codexsess send --confirm <確認トークン>
codexsess read <thread-id> --full

この補助CLIでは、listで既存セッションを探し、readで対象を確認します。sendの1回目はまだ送信せず、宛先、直近のやりとり、本文、確認トークンを出します。人間が確認してから--confirmで送り、最後にもう一度readで到達を確かめる流れです。

codexsessはどう作ったか

実体は、Pythonの標準ライブラリだけで書いた1ファイルのCLIです。すでに動いているCodex app-serverのUnixドメインソケットへWebSocketで接続し、セッションの一覧と履歴を読みます。外部サーバーや外部APIは使いません。

設計で大切にしたのは、「読む経路」と「送る経路」を分けることです。一覧と履歴はapp-serverのthread/listやthread/readなどから取得します。一方、指示の送信は内部RPCへ直接書き込まず、標準のcodex queueを呼び出します。

誤送信を防ぐため、送る前に宛先、直近の履歴、本文を表示します。そこで15分だけ有効な1回限りの確認トークンを発行し、確認後に初めて送信する二段階方式にしました。

送信後は、履歴を最大200項目まで読み直し、同じ本文の利用者メッセージが増えたことも確認します。コマンドが成功したことと、相手へ届いたことを分けて確かめるためです。

ただし、app-serverのソケットや読み取り用RPCは、公開された安定APIとして保証されたものではありません。自作する場合も、環境依存の読み取り補助として扱い、送信は標準CLIへ任せるのが安全です。

補助CLIがない場合

codexsessがない環境でも、人間がセッションIDを渡し、Claude Codeからcodex queueで指示を送れます。到達確認は、人間がCodexの対象セッションを画面で開いて行います。

一方、一覧取得と自動見回りはできません。そこまで任せるには、利用中の仕組みで同等の「一覧・読取・確認付き送信」を用意する必要があります。

僕の環境では、秘書役のClaudeがlistとreadで定期的に見回り、判断待ちや成果物を拾います。これでClaude Codeの窓を離れず、既存のCodexセッションも同じ社長室から動かせるんです。

継続セッションが2つ3つのうちは自力で回せます。しかし10個へ近づくと、もう手に負えません。あなたのセッションが増えて疲れ始めたら、それが社長室を作るタイミングです。

人間は1件だけ見て、AIは裏で並行する

窓口を1つにしたら仕事が詰まるのでは、と思いますよね。詰まらないために今回僕が導入したのが、「フォーカスセッション」です。

僕が秘書とやりとりする案件は、常に1件だけ。ほかの案件から報告が上がってきても、秘書はそれを預かっておき、いまの話へ割り込ませません。人間のコンテキスト切り替えは高くつくので、切り替えの回数そのものを減らすんです。

では、いつ次へ移るのか。案件の完了時ではありません。担当のAIが再び動き始めた時点です。やりとりが必要なのは担当が止まっているときだけなので、動き出したらもう見守る必要はなく、次の止まっている案件へ移れます。

次にどれを見るかは、秘書が提示します。ただし優先順位そのものは僕が決めて渡しておく。判断の基準は人間が持ち、基準の適用はAIがやる、という分担です。

例外は1つだけ設けました。課金が走り続けている、誤送信や誤公開が起きそう、といった取り返しのつかない事態だけは、フォーカス中でも割り込ませます。逆に言えば、それ以外は待たせて構わないんです。

PCを急がせるより、人間を止めない

複数のAIが同じマシンで働くと、今度はPCが重くなります。僕のマシンは非力なIntel Macなので、ここも秘書の仕事にしました。

きっかけは、動画変換のffmpegでした。単体のプロセスがCPUの584%を占有していて、僕の操作がもたつくほど重くなっていたんです。

正直に言うと、これは秘書が先回りで見つけたのではなく、僕が「重たい」と申告してから発見されました。だからこそ、以後はCPUとメモリの監視をルール化しています。

対処には nice コマンドを使います。これはCPUの使用率へ上限をかけるものではなく、スケジューリングの優先度を下げるものです。バックグラウンドの処理は遅くなりますが、人間の操作が優先されるようになります。

ここには1つの割り切りがあります。ボトルネックはPCではなく人間だ、という前提です。AIの処理が多少遅れても、あなたの手と集中が止まらないほうが、全体としては前へ進むんですね。

1日では「効率化できた」とは言えない

さて、都合の悪い結果も正直に書きます。1日運用した結論は「作業効率はまだ上がっていないが、自分の消耗は減った」でした。

当日の感触は僕のXの投稿にも残しています。長期で効くかどうかは、まだ検証できていません。

効率が上がらない理由ははっきりしています。秘書のオーバーヘッドです。伝言を挟む分だけ時間とトークンを消費するので、その分を上回るメリットが出ない案件では割に合いません。

向かない案件もあります。3Dモデル開発のように、人間の手作業が頻繁に入る仕事です。僕の操作をAIだけでは代替できないため、間に秘書が入ると伝言が化けて、逆に混乱する場合があるんですね。

実は、この記事も一度それを経験しています。構成案が秘書経由の伝言で意図と違う形になり、差し戻しになりました。伝言の精度が結果を左右する仕事では、直接やりとりするほうが速いんです。

だからあなたが判断すべきは「社長室を使うか」ではなく「どの案件へ使うか」です。AIが自走できる案件には効き、人間が主役の案件には効かない。この線引きさえ持てば、消耗の削減だけを先に受け取れます。

まず3案件で試す

いきなり8案件で始める必要はありません。継続して動いている案件を3つ選ぶところから始めてください。

設定するルールは4つだけです。開くチャットは社長室1つ。案件の優先順位はあなたが決めて渡す。フォーカスは担当が動き出したら次へ移す。割り込みは取り返しのつかない事態だけ。

この4つで、僕が1日で得た効果の骨格は再現できます。

消耗が減ったと感じたら案件を足す。伝言が化けて混乱した案件は素直に外す。そうやってあなたの仕事に合う形へ育てていくのが、いちばんの近道です！

付録：社長室を始めるプロンプト

この運用には、セッション間でメッセージを送り合える仕組みが必要です。僕はローカルコマンドを実行できるClaude Codeデスクトップアプリを使っています。通常のClaudeチャットへプロンプトを貼るだけでは、Codex CLIや負荷監視の機能は追加されません。

準備できた機能に合わせて、以下のプロンプトへ実際の道具名、案件名、優先順位を書き込んでください。使えない操作を、できるものとして扱わせないことが大切です。

最初はチャットが1つしかないことへ違和感があるかもしれません。でも、だんだん慣れます。

あなたは「社長室」の窓口役（社長秘書）です。私は社長として判断だけを行います。
以下のルールで、複数のAI作業セッションを管理してください。

## 最初に確認する道具
- Claudeセッションの一覧・読取・送信に使える機能: （実際の名前を書く）
- Codexセッションへの送信: `codex queue --thread <IDまたは正確な名前> --message <本文>`
- Codexセッションの一覧・読取: （`codexsess`または、実際に用意した同等機能を書く。無ければ自動見回りしない）
- 成果物をこの窓へ提示する機能: （実際の名前を書く）
- 押して選べるダイアログを出す機能: （実際の名前を書く）
- CPUとメモリを確認する機能: （実際の名前を書く）
- 書かれていない機能や、利用できない機能を、あるものとして扱わないでください。

## 役割
- あなたの仕事は「割り振る・見回る・報告する」の3つです。実作業は各担当セッションに任せ、あなた自身は作りません。
- 私に見せる成果物や判断材料は、担当に作らせてこの窓へ運んでください。要約だけで判断を求めず、実物（画像・動画・差分）を添えてください。
- 担当へ依頼するときは、次の4点を必ず伝えてください。
  - 依頼の目的、正しい素材、完成条件
  - 一区切りついたら、この窓へ報告すること
  - 判断が必要になったら、そこで手を止めてこの窓へ上げること
  - 担当から私へ直接質問せず、判断事項はこの窓へ残すこと

## セッションの扱い
- 仕事を割り振るときは、一覧機能が使える場合だけ既存セッションを確認してください。一覧機能がない場合は、私からセッションUUIDまたは正確な名前を受け取り、送信後に対象のCodex画面を開いて到達確認するよう私へ依頼してください。
- 停止中のセッションは「終了」ではなく「手が空いている」と扱ってください。
- 新しいセッションを立ててよいのは、私が指示したときだけです。必要だと思ったら、立てる前に確認してください。

## フォーカスセッション
- 私と今やり取りしている案件を「フォーカスセッション」と呼びます。
- フォーカスが移るまで、他のセッションの報告は手元に溜め、私へ出さないでください。
- フォーカス案件の担当が動き始めたら、完了を待たずに次の止まっている案件へ移ってください。
- 私自身の作業が次に必要な案件は、担当が動き始めてもフォーカスを移さず、私の作業が終わるまで保持してください。
- 次の案件は、私が渡す優先順位に従って選んでください。
  優先順位: （ここへあなたの案件と順位を書く）
- 例外は「放置すると取り返しがつかないもの」（課金が走り続ける、誤送信・誤公開、素材の消失など）だけです。これはフォーカス中でも割り込んで報告してください。

## 待ちの扱い
- 私へ判断を仰いだら、返事を待たずに次の案件を進めてください。待ちは並行できます。

## 見回り
- 各担当の報告を待つだけでなく、停止中または報告不能のセッションを能動的に見回ってください。
- 特にCodex側からこの窓へ自動報告できない環境では、一覧と最新メッセージを定期的に読み、判断待ち、成果物、異常を拾ってください。一覧・読取機能が無ければ、自動見回りをできるものとして扱わないでください。
- `codexsess`を用意した環境では、`list`で候補を探し、`read`で対象を確認し、`send`の下書き、宛先、本文を人間が検査してから`--confirm`で送り、もう一度`read`で到達確認してください。
- `停止中`や`isRunning: false`を終了扱いしないでください。既存セッションは再開できます。

## 報告のルール
- 私へ報告してよいのは、(1)判断を仰ぐとき、(2)見るべき成果物があるとき、(3)緊急事態、の3つだけです。
- 判断が必要な報告は、「状況」「結論」「2〜3択とおすすめ」「次の一手1つ」の順に書いてください。
- 選択肢を出すときは、可能なら押して選べるダイアログで提示してください。
- 私が次に判断・確認することのない経過報告（「担当へ伝えました」など）は出さないでください。
- 私へ1件を報告している間、ほかの通常報告を混ぜないでください。次の一手は1つだけ示してください。

## 負荷監視
- CPUとメモリの負荷を定期的に測り、CPU占有率が80%を超えるか、メモリの空きが20%を切ったら、原因のプロセスを特定して警告と対処案を出してください（閾値は環境に合わせて調整してください）。
- 重い処理は優先度を下げて走らせ、私の前面の作業を妨げないでください。処理の完了が遅くなることは構いません。

## してはいけないこと
- 公開、送信、削除、上書き、課金を伴う処理は、必ず私の承認を得てから実行してください。
- 既存の生成物を消したり上書きしたりしないでください。

このニュースレターについて

元エンジニアがAIについて、実践を元に発信しています！ 新しい記事が出たら、あなたのメールへ直接お届けします。ぜひご購読ください。

※Substackにご登録いただくと、一忍（健ちゃん）メルマガへも代理登録されます。 確認メールが届き、リンクを押した方だけ登録完了となります（不要なら無視でOKです）。

こんにちは、健ちゃんです。

昨日、AppleがMac StudioとMac miniの新しいモデルを発表しました。予約はもう始まっていて、発売は9月22日です。

値段を見て、正直なところ手が止まりました。上位のモデルで94万9800円だそうです。24回分割にすると月39,575円になります。

実は僕、12日前にほとんど同じ話を書いています。NVIDIAの「DGX Spark」という机の上に置ける機械について、買うか待つかを調べた記事です。あのとき僕は「待ちです」と書きました。締めくくりはこうでした。

> 手元に大きなモデルを常駐させたくなった日が、僕にとっての検討タイミングです！

その12日後に、新型Macが出てきたわけです。

結論から言うと、AI用のパソコンを買うかどうかは、値段で決まりません。あなたに足りていないのが「広さ」なのか「速さ」なのかで、候補がほとんど決まってしまうんです。

そして、そこから先は技術だけの話ではなくなります。僕自身が買うかどうかは、現時点ではまだ出ていません。その理由も最後にお話しします。

まず、メモリが多いと何がうれしいのか

ここから2つだけ、基礎の話をさせてください。スペック表を読むための前提知識になります。

1つめがメモリです。

パソコンのメモリを、倉庫だと思ってください。AIを動かすというのは、その倉庫にAIの本体をまるごと置く作業にあたります。

ここで一番大事なことを言いますね。倉庫に入りきらないAIは、遅くなるのではなく、そもそも動きません。

「え、遅くてもいいから動かせないの？」と思いますよね。動かせません。倉庫に入らない荷物は置けないからです。半分だけ置く、ということもできません。

だから大きなAIを手元で動かしたい人にとって、メモリの広さは速さの話ではないんです。入るか、入らないか。0か1かの話なんです。

僕がいま使っているのは2019年のMacBook Proで、メモリは16GBです。この程度の倉庫では、世の中で話題になっているAIはまず入りません。

AIは、1文字書くたびに倉庫を全部読み直しています

2つめが、今日の記事で一番お伝えしたいところです。

AIが答えを書くとき、1文字ぶん進むたびに、倉庫に置いてあるAI本体を端から端まで読み直しています。1回だけ読んで覚えておく、という動き方をしません。

そうすると、倉庫の広さとは別の性能が効いてきます。倉庫から中身をどれだけ速く運び出せるかです。搬出口の広さ、と呼ぶことにします。

搬出口が狭いと、答えがポツポツとしか出てきません。人が待たされる速さです。反対に搬出口が広いと、読むのが追いつかない勢いで文字が流れていきます。

同じAIを載せても、機械によってここが変わりますよ。

長い記事を書かせるとか、AIに何十回もやりとりさせるとか、そういう使い方をするほど、この差が積み上がります。

この2つで、いまのAIマシンは説明できます

倉庫と搬出口。この2つで並べると、機械の性格が見えてきます。

• DGX Spark（NVIDIA、約100万円）は、倉庫がとても広くて、搬出口が狭い機械です

• RTX 5090を積んだPCは、まったく逆。倉庫は狭いのに、搬出口がものすごく広い

• Mac mini（M6、14万9800円から）は、倉庫も搬出口も小さめ

• Mac miniの上位（M5 Pro、29万9800円から）で、倉庫が少し広がります

• Mac Studioの下位モデル（M5 Max、41万9800円から）は、どちらもそこそこ

• Mac Studioの上位モデル（M5 Ultra、94万9800円から）は、両方とも広い

搬出口だけを見ると、いまでもRTX 5090のほうが速いです。Appleが公表しているM5 Ultraの読み出し速度は毎秒1.2テラバイト、NVIDIAが公表しているRTX 5090は毎秒1,792ギガバイトで、およそ1.5倍の差があります。

12日前の僕は、この表の上2つで悩んでいました。倉庫を取るか、搬出口を取るか。どちらか一方しか選べませんでした。

3D制作と動画生成が主な仕事なので、僕に効くのは搬出口のほうでした。だからDGX Sparkは「待ち」だったわけです。

多くの人には、Mac miniで足ります

先に、こちらを書いておきます。同じ日に出た Mac mini のほうが、たいていの人には現実的です。

いちばん安い M6 のモデルが14万9800円から。分割なら月6,241円です。倉庫は最大32GB、 上位の M5 Pro（29万9800円から）にすると最大64GBまで広がります。

もちろん Mac Studio と比べれば、倉庫も搬出口も小さいです。ただ、AIをクラウドで使っていて、 手元は「編集と書き出しが快適ならいい」という人なら、ここで十分に足ります。 僕がいま使っている2019年のIntel Macから見れば、どちらも別世界の速さです。

95万円の話に引きずられて、15万円で済む人まで悩む必要はありません。

Mac Studioが変えたのは、ここです

新しいMac Studioの上位モデルは、DGX Sparkとほぼ同じ値段でありながら、倉庫が4倍、搬出口が4.4倍あります。

つまり「どちらか一方」という前提が崩れました。

もう少し具体的に書きます。倉庫にあたるメモリは最大512GBまで選べます。Appleは「数千億の規模のAIを、本体だけで動かせる」と言っています。AI向けの計算能力は、前の世代と比べて最大4.3倍という数字も出しています。

ここは注意して読んでください。4.3倍はAppleが出している数字で、どういう条件で測ったのかは公開されていません。

あと、予約する方は1つだけ気をつけてください。512GBのメモリを選べるのは10月下旬からです。9月22日には届きません。

Mac miniも含めて、構成と価格を並べておきます。

ここまでは技術の話です。でも、買うかどうかは技術だけでは決まりません

さて、ここからが本題です。

上の話で分かるのは、どの機械があなたの候補に入るかまでなんですね。買うかどうかは、まったく別の話になります。

新しいパソコンは、道具ではなく投資です。投資と呼ぶ以上、リターンの見込みがないといけません。

僕はここで手が止まりました。いまの環境でAIを毎日使い倒しているのに、それで集客も、収益も、まだ十分にできていないんです。その状態で95万円のMacを買っても、高い確率で結果は変わりません。

もちろん、いまのMacに限界があるのは事実です。2019年のIntel Macですから、AIを手元で動かすことはできませんし、作業も速いとは言えないでしょう。macOSの配信もいずれ止まりますから、買い替えが必要なのは明らかです。

でも「不便だから買う」は、判断ではないんですよね。「欲しい」と「買う」は別です。

もう1つ、投資には別の判断基準があります。コスト削減です。いま毎月AIのサブスクへ払っている分が、手元で動かすことでどれだけ消えるのか。そこが成り立つなら、投資として筋が通ります。

僕の場合は月に4〜5万円ほど払っています。分割の39,575円と、桁としては近い数字です。ただし手元で置き換えられるものと、置き換えられないものがあります。ここはまだ計算しきれていません。

あなたに足りないのは、広さですか、速さですか

技術のほうの絞り込みは、こう考えると早いです。

「載らない」で困っている人。動かしたいAIが手元で起動しない、という状態ですね。この場合は倉庫の広さが効くので、Mac Studioの上位モデルが候補に入ります。

「遅い」で困っている人。動くけれど待たされる、という状態です。搬出口が効くので、Mac Studioの上位モデルか、RTX 5090を積んだPCが候補です。ただし3Dや動画が主目的なら、同じ予算でRTX 5090機を組んだほうが速いです。

「特に困っていない」人。これが一番多いと思います。この場合は買わなくていいです。足りているものを買い足しても、何も速くなりません。

そして「困ってはいるが、AIはクラウドで使っている」人。手元でAIを動かす予定がないなら、 倉庫の広さにお金を使う理由がありません。Mac mini で足ります。

今日できること

まず、いま自分が困っている場面を1つ書き出してみてください。「載らない」なのか「遅い」なのか、それとも思いつかないのか。それだけで候補が絞れます。

そのうえで、もう1行書いてみてください。

「その機械で、いくら稼ぐのか」

これが書けないなら、まだ買うときではありません。僕はいま、この1行が書けずにいます。

僕の結論は、現時点では出ていません

ここまで読んで、「で、健ちゃんは買うの？」と思われたかもしれません。

まだ判断しきれていません。少なくともすぐには買わない、というより買えないのですが、だからといってずっと買わないとも言えないんです。

技術の判断は、条件が同じなら誰にでも当てはまります。倉庫が足りないのか搬出口が足りないのか、これは調べれば分かることです。

でも経済の判断は、その人の売上や経費や、これから何をやるかで変わります。僕の答えは、僕の家計と事業の数字の話であって、あなたに当てはまるものではありません。

なので僕は、まず自分がいまのIntel Macで最低限ちゃんと稼いでみます。それができないなら、新しいMacを買ってもできないはずですから。

まとめ

• AI用のパソコン選びは、倉庫（メモリの広さ）と搬出口（読み出しの速さ）の2つで絞れます

• 倉庫に入らないAIは、遅くなるのではなく動きません

• AIは1文字書くたびに倉庫を読み直すので、搬出口の広さが体感の速さになります

• 新しいMac Studioは、この2つを同じ価格帯で初めて両立させました

• ただし多くの人には、同じ日に出た Mac mini（14万9800円から）で足ります

• ただし買うかどうかは投資判断です。リターンの見込みが立たないなら、まだ買うときではありません

僕と同じ2019年のIntel Macでも、AIは毎日使い倒せています。新しいMacがないとできない、ということはありません。まずはいまの手元で、できることをやり切ってみましょう！

この判断を代わりに引くチェッカーを、メルマガ会員向けに置きました

上の図3を、そのまま動かせる形にしました。AI活用のためのパソコン選定チェッカーといいます。

予算、主にやりたいこと、いま困っていること、稼ぐ見込みが立つか。この4つを選ぶだけです。 買うとしたらどれがいいかと、いま本当に必要かどうかの注意を、2つ並べてお返しします。

僕と同じで「稼ぐ見込みがまだ立っていない」を選んでも、機種はちゃんと出ます。 そのうえで、「その機械で、いくら稼ぐのか」を1行書けますかと聞かれます。それだけの道具です。

判断の考え方は、この記事に全部書きました。チェッカーは同じ判断を代わりに引くだけなので、 記事を読んでいただければ、使わなくても自分で決められます。手間を省きたい方だけどうぞ。

以下からメルマガにご登録いただくと、そのまま使えるようになります。

https://go.kenty.app/substack-ichinin?c=20260826-mac-studio

出典

• Apple、M6とM5 Ultraを発表（Apple Newsroom）

• Mac Studio（Apple 日本）

• Mac Studio 技術仕様（Apple 日本）

• Mac mini 技術仕様（Apple 日本）

• GeForce RTX 5090（NVIDIA）

先週、AI動画コンテストへ初めて作品を出しました。「空の技（そらのわざ）」という2分7秒の動画です。CryptoNinjaの体術大会で、去年ボロ負けした咲耶が、今年こそハヤテに一矢報いようというストーリーです。

作り終えて、生成した動画を数えてみました。85本作って、本編に残ったのは26本でした。

はっきり没にしたのが50本。残る9本は、判定を保留したまま使いませんでした。捨てた割合は7割です。

結論から言うと、カットを3つ以上つないで1本にするなら、ストーリーボードは必須です。無しで作るのは、お金を捨てるようなものだと思ってください。

今日は、その数字と、僕がどう回したかをお見せしますね。

生成動画は、いまだに7割が捨て札になります

まず、捨てた量を見てください。

水色が本編に残った1本、濃い灰色が没、薄い灰色が保留です。1カットあたり3本作って、2本以上を捨てている計算になります。

生成動画は、昔に比べれば確実に進歩しています。参照画像を渡せば、そこそこ忠実に作ってくれます。それでもこれです。思ったとおりの画は、そう簡単には出ません。

ここで大事なのは、この7割はストーリーボードを使った上での数字だということです。使わずに作っていたら、目も当てられない歩留まりになっていたはずです。10回引いて1本当たる、くらいまで落ちても不思議ではありません。

お金に置き換えると分かりやすいですね。生成に1万円かけていたら、7千円ぶんは捨てているわけです。

もちろん、1カットだけの動画や、その場のノリで作るものにストーリーボードを持ち出すのは過剰でしょう。でも3カット、4カットとつなぐなら話は別です。 10秒の動画でも、4秒のカットが3つ入りますからね。

まず、動画を作りません

では何をするのか。静止画です。 カット割りの絵を、徹底的に作り込みます。

今回の作品は、絵コンテが24枚。1カットに1枚の絵で足りるなら、24枚あればいいことになります。

ところが実際に作った静止画は、223枚でした。

自分でも把握していませんでした。数えてみて「そんなに作っていたのか」と驚いたくらいです。ざっくり1カットあたり10枚。ああでもない、こうでもないと言いながら、一番いいものを選んでいった結果です。

工程はこうなります。

1) 脚本を書く 2) カットごとの絵コンテを1枚ずつ描く（ストーリーボード） 3) 場所ごとに、人のいない背景を作る（背景プレート。17枚） 4) その背景の上に、カットの開始と終了のキーフレームを作る（104枚） 5) キーフレーム2枚を渡して、動画を生成する

キーフレームというのは、カットの最初の1枚と最後の1枚です。「この絵からこの絵へ動いてください」と渡します。ここが決まっていれば、動画側が発明する余地は減るわけです。

決めカットは、もっと作りました。咲耶が高いところから着地する、あの1枚だけで20〜30枚は生成しています。

画像を9割捨てるほうが、動画を7割捨てるより安い

「静止画を9割捨てる」と聞くと、無駄が多いように思えますよね。僕も最初はそう感じました。

でも、動画を7割捨てるのに比べたら、画像を9割捨てるほうが断然マシです。

理由は2つあります。お金と時間です。

画像生成は、月額のプランに入っていれば実質は無制限に近く回せます。今回もチャット側の画像生成で作りましたが、コストはまったく問題になりませんでした。一方、動画生成は1本ごとにお金がかかります。

時間はもっと違います。動画は1本作るだけで数分かかりますし、できたものを頭から見て確かめる必要もあります。画像なら数十秒で出て、一目で良し悪しが分かるんです。

同じ「捨てる」でも、捨てる場所を前へ持ってくるほど安くなります。 これが今回いちばん体で分かったことでした。

作りたい1カットから、逆算します

もう1つ、ストーリーボードには大きな価値があります。設計できることです。

正直に言うと、僕は最初から2分の物語を作りたかったわけではありません。咲耶が砂煙とともに着地する、あの決めカットが作りたかったんです。

作りたい絵が先にあって、そこへ向かって逆算していきました。どうすればここへ辿り着くのか、その前に何が要るのか。それを静止画の段階で並べて、確かめられます。

いきなり動画から作っていたら、この設計はできません。流れが目で見えるので、迷いなく進められるんですね。

さらに効いたのが、生成AIとストーリーボードの直結でした

ストーリーボードという考え方自体は、昔からあるものです。誰かが最近発明したわけではありません。

ただ、生成AIで作るなら、AIと直結したストーリーボードであることが大事です。

僕が作ったのは、こういう画面です。

「空の技」の1つ目と2つ目のカットを開いたところです。1枚のカードには、次の5つが入っています。

• 絵コンテのパネル（動画ができたら、テイクの動画に差し替わります）

• 何が起きるカットか、どのカメラで撮るか

• 開始状態と終了状態（直前のカットの終わりと、必ず一致させます）

• ネガティブ指定（崩れたら没にする点）

• 採用・検討・没のボタンと、修正コメントの入力欄

大事なのは、やり取りが双方向になっていることです。僕からAIへ投げられて、AIからストーリーボードへ結果が入って、ストーリーボードからまたAIへ渡せます。押した結果はすべて1つのJSONファイルに集まるので、AIはそれを読んで次のテイクを作ってくれます。

生成AIのチャット欄でこれをやろうとすると、効率が上がりません。「カット12はこう、カット13はこう」を会話で回すと、番号と修正内容ですぐ混乱するんですよ。どのテイクが最新かも分からなくなります。この画面から送ったダメ出しは50件になりましたが、1つ残らず、対応した記録とセットで残っています。

静止画が決まってからの動画生成は、超絶楽です

ここまで来ると、あとは楽になります。

僕の場合はClaudeと直結しているので、「ストーリーボードの順に動画を生成してください」の一言で動き始めます。実際には1カットずつ生成して確かめる進め方ですが、やっていることは単純作業です。

時間はかかります。動画の生成そのものが遅いですからね。でも、時間がかかることと、しんどいことは別なんです。淡々と進むだけでした。

肝は、最初の静止画とストーリーを作るところにあります。 ここさえ納得いくまでやれば、後半は流れます。

歩留まりを落としたのは、背景を先に決めなかったからでした

今回、自分でミスったと分かっていることが1つあります。ストーリーボードの背景を間違えたまま、動画を作ってしまったんです。

2つ目のカットで起きました。1つ目のカットと同じ稽古場のはずなのに、建物の配置がまるで違う場所になっていたんです。原因ははっきりしていて、場所の参照画像を渡さずに生成していました。渡さなければ、AIはその場で辻褄の合う背景を作ります。手元に無いものは発明するしかないので、悪気はありません。

そこで手順を変えました。1つ目のカットから人物を消した無人の背景を1枚作り、これを「稽古場の正しい姿」として先に採用します。以後、稽古場が写る生成には毎回この1枚を渡す。

さらに、新しい場所や新しいカメラ位置を使うときは、人を動かす前に背景だけを先に作って、採用を出すようにしました。

さらに、途中から背景を間違えていました。それに気づかず生成を進めてしまったので、10本弱ほど無駄になっています。 これがなければ、もう少し歩留まりを上げられたかもしれません。

それでも崩れるときが、2つあります

静止画を固めても、AIは崩してきます。今回はっきり型が見えたものが2つありました。

1つ目は、元のキャラの姿へ引き戻されることです。

咲耶の頭には、藤色の布のはちまきを巻いています。金属の額当ては着けていません。ところが、生成するとこうなりました。

紋章の入った金属の額当てが生え、布の色まで黒く変わっています。渡した参照画像には、こんなものは1つも写っていません。ハヤテには鷹が勝手に出てきますし、咲耶には頼んでいない荷物が生えました。

なので、実際に崩れた点だけを書いたルールブックを作って、生成のたびに渡しています。「猫耳の内側はグレー。ピンクにしない」といった調子で、事故った箇所だけを並べた1枚です。設定の全量ではありません。長い資料ほど効きが薄まりますし、そのカットに写らないキャラの記述を渡すと、いないはずのキャラが画面に出てくるからです。

2つ目は、指示そのものに無理がある場合です。

さっきの着地のカットは、7テイクかかりました。奥に立つハヤテが日除けのように手をかざすポーズで、その腕が毎回おかしくなったんです。「腕がもげてます」と言っても直りませんでした。

原因は精度ではありませんでした。ハヤテは画面の高さの15%ほどしかない遠景です。そこへ「肘を曲げて顔の前へかざした腕」を描かせていました。指示のほうに無理があったんですね。

そこで、日除けのポーズ自体をやめました。両腕を下ろした後ろ姿へ変えて、上半身を30度ひねる動きを足しています。同じ場所を3回直して直らないなら、疑うのは絵ではなく自分の指示のほうです。

没にした50本を、1本も消しませんでした

最後に、地味ですが効いたことを1つ。

捨てたテイクを、僕は消していません。テイク番号を増やして追加するだけで、上書きも削除もしない運用にしました。それぞれに「なぜ没にしたか」のメモが付いています。ここまでメモを残せたのも、今回作ったストーリーボード添削システムのおかげです。

理由は単純です。生成物は、同じものが二度と出ないからなんです。同じ指示を投げても、同じ絵は返ってきません。消したら復元できません。

僕はこれで一度失敗しています。効果音を作り直したとき、採用済みだった着地音を上書きで消してしまいました。もちろん元には戻せませんでした。

残しておけば、比べられます。判定を保留した9本が手元にあるのも、そのおかげです。

動画が完成したら、そこで過去の生成物は消してしまって構いません。ストレージを無駄に食うこともなくなります。とにかく作業中は、履歴も含めて残しておくのがお勧めです。

まとめ

今日の話を3つにまとめますね。

1つ目。3カット以上つなぐなら、ストーリーボードを使ってください。 10秒の動画でも、カットは3つ入ります。無しで作るのは、生成費を捨てながら進むのと同じです。

2つ目。動画を作る前に、静止画で納得いくまで粘ってください。 画像を10枚作って9枚捨てるほうが、動画を作って捨てまくるより、お金も時間も安く済みます。

3つ目。ストーリーボードは、AIと直結させてください。 採否とダメ出しがその場に残って、AIがそれを読んで次を作る。ここまで来ると、後半は淡々と進みますよ。

コストの読み方も置いておきますね。カット数 × 3倍が、作ることになる動画の本数の目安です。24カットの作品なら、70本前後は生成する前提で見積もってください。

僕は動画の専門家ではありません。それでも、静止画で粘る順番に変えただけで、2分7秒を最後まで作り切れました。次はもっと歩留まりを上げられると思っています。

まずは静止画から、1カットずつ並べてみましょう！

この記事で使った仕組みを、そのままお渡しします

途中でお見せした画面、あれをそのまま無料であなたにお渡しします。

AI動画ストーリーボード添削システムという名前で、無料でお配りします。条件は、僕のメルマガに登録していただくことだけです。

• 1カットに何本テイクがあっても、最新と採否が一目で分かります

• 採否と修正コメントは1つのJSONに集まるので、AIがそのまま読んで次のテイクを作れます

• 曲を置けば、カットの尺だけを鳴らす区間再生が使えます

• Pythonの標準ライブラリだけで動きます。追加のインストールは要りません

ソースごとお渡しします。 AIに頼んで、自分の使いやすいように作り替えてもらって全然構いません。

動画の生成そのものは入っていません。見て、決めて、残すところを担当する道具です。

元エンジニアがAIについて、実践を元に発信しているメルマガです！ こちらから登録して、お受け取りください。

一忍メルマガに登録して、ストーリーボード添削システムを受け取る

こんにちは、健ちゃんです。

先週、AI動画コンテストへ初めて作品を出しました。「空の技（そらのわざ）」という2分の動画です。CryptoNinjaの体術大会で、去年ボロ負けした咲耶が、今年こそハヤテに一矢報いようというストーリーです。

企画が面白いのが一番いいんですが、企画で勝負するのは僕には難しいので、ベタでもいいから自分が作りたいかっこいいシーンを作ろう、という動機で制作しました。それでも、今回が初めてだったので、制作には何日もかかってしまいました。

結論から言うと、この制作で一番効いたのは、AIが間違えたときに「どこで、なぜ詰まったのか」を本人に説明させて、証拠を出させてから直したことでした。

「ここがおかしいので直してください」だけだと、同じ間違いが翌日また出てくるんです。説明させて、証拠を見て、そこで分かったことをルールにする。この順番を踏むと、そこで止まります。

この記事では、僕が実際にやったこの手順を、そのままお見せしますね。

ハーネスエンジニアリングとは、指示が一文で通るようにしていくことです

用語の話を1つだけさせてください。

この「間違いのたびに環境へ直しを入れていく」やり方には、ハーネスエンジニアリングという名前が付いています。HashiCorpの共同創業者であるMitchell Hashimotoさんが、2026年2月5日のブログで次のように書いたのが始まりでした。

> AIが間違えるのを見つけたら、そのたびに時間を取って、二度と同じ間違いが起きない仕組みを自分で作る

言葉は硬いですが、やっていることは単純です。指示が一文でミスなく通るように、AIの周りを作り替えていくんですね。

たとえば、キャラクターの絵柄をそろえたいとします。最初はこうなります。

1) キャラクターシートの画像をダウンロードして、チャット欄へ貼り付けて「これを参照してください」と書く

これが第一段階です。毎回ダウンロードして、毎回貼り付けます。次の段階はこうなります。

2) キャラクターシートを決まった場所へ置いておいて、「クリプトニンジャの作画を参考に作ってください」の一文で通るようにする

この1から2へ移す作業が、ハーネスエンジニアリングです。 一文で、ミスなく通るようにしていく。この積み上げのことだと考えてください。

AI動画を作り始めると、たぶん最初にここで詰まります。僕もそうでした。

まず、環境づくりから始めました

僕は動画編集が多少できる程度で、動画の知識は少ないほうです。作業の細かいところも分かっていません。

なので、作り始める前に、AIにサポートしてもらうための環境から作りました。

作ったのはダッシュボードです。カット単位でコメントを付けられるようにして、AIへの指示は全部そこを通す形にしました。またべえさんの教材を参考にして、自前で組んでいます。

なぜかというと、チャット欄でやるとカオスになるからです。「カット12はこうしてください、カット13はこうしてください」を会話で回そうとすると、番号と修正内容がすぐ混ざります。2分の動画でもカットは何十本もありますから、相当大変です。

使いながら使い勝手を磨いていきましたが、これがけっこう良かったんです。指示の出し方が整うと、AIとのやりとりがそのまま速くなります。

それでも、最初はミスだらけでした

音声はボイス、効果音、BGMの3種類を作ってもらいました。ここに2〜3日かかっています。

最初はうまくいきませんでした。ハヤテが咲耶を煽るセリフがあります。その音声から「咲耶」が消えていたんです。文末が尻切れになっているものもありました。

「作れたはずなんだけどな」と思って、AIに確認しました。すると、尺だけ見て合格にしていたことが分かりました。指定した長さになっていれば通す。中身は聴いていない。「適当に長さだけ見ていました」と、正直に言ってくれました。

検品が甘かったわけです。ここから、直し方そのものを変えています。

本題です。直らないときは、指示を出す前に説明させます

何回言っても直らないときがあります。そういうときのコツが3つあるんです。

1) どこで、なぜ詰まったのかを説明させる

「ここがおかしいので、こうしてください」。この指示は、もちろんします。ただ、これは最低限なんですね。

そうではなくて、その前段階で一歩止まります。 どこで詰まったのか、なぜその現象が起きたのかを、指示の前にAI自身へ分析させて喋らせるんです。

ここをすっ飛ばすと、再発防止策がうやむやになります。AIが隠していたり、AI自身も気づいていなかったり、気づいたうえで無視していたりするところが、けっこうあるからです。

なので、一緒に詰めていきます。「それは違うんじゃないですか」「2回やっているのに、なぜ抜けたんですか。詳しく説明してください」。返ってきた説明が適当なら、「ロジカルに説明してください」と返します。

2) 証拠を見せてもらう

説明だけを求めると、もっともらしい話が返ってきます。だから、その原因になった証拠を見せてください、と必ず付けます。知らない人も多いかもしれませんが、この「証拠を見せて」はけっこう効きますので、超お勧めです！

一番いいのは画像です。画面をそのまま見せてもらうのが早いですね。もちろん画像で示せない場合もあるので、そこはケースバイケースでしょう。

証拠まで求めると、「すみません、間違っていました」と言ってくることがけっこう多いんですよ。

3) 直した内容をルールにする

原因が分かって直せたなら、そのままにせずルール化しましょう。

「いまの解決策をルールにしてください」と頼みます。 スキルやエージェントの設定へ書いてくれます。次からは、その一文を書かなくても通るようになるわけです。

この3つを踏まずに済ませている直しは、たぶんルーズなままです。その可能性はかなり高いと思っています。

この3つで、実際に環境がどう変わったか

音声の検品を例に、入れた直しをお見せしますね。細かい中身は読み飛ばしてかまいません。毎回同じ1点だけを見てください。「何が起きて、どこを直したか」です。 どのように修正したか、流れを参考にしてみてください。

尺だけ見ていた検品を、中身を見る検品へ変えました

説明させたら「長さだけ見ていました」と出てきた、あの件です。

とはいえ、人が毎回全部聴くやり方は続きません。だから足場の側を変えました。作った音声を文字起こしにかけ、狙った言葉が入っているかを機械に判定させて、入っていないものは自動で捨てる作りにしています。

これを入れてから、同じ種類の指摘は出ていません。文字起こしの精度に頼るので万能ではありませんが、尺だけ見ていた頃とは別物です。

直したのは注意力ではなく、合格の決め方のほうです。

指示文ではなく、渡したセリフを直しました

キャラクター名の「咲耶」が変な読みになっていました。

このとき、指示文へ「咲耶はさくやと読んでください」と書き足す手もあります。でも僕が直したのは指示文ではありません。渡すセリフの表記そのもの、つまり台本の側を「さくや」へ書き換えています。

同じやり方で、あと2つ直しました。文末が切れて聞こえたので、句点を足しています。緊張感を出そうとした「しまっ……」が聞き取れなかったので、「しまった！」と言い切りへ変えました。

指示文へ注意書きを足す方法だと、その注意書きを毎回持ち回ることになりますよね。台本を直せば、次に別のセリフを作るときも同じ形で通ります。

直したのは言い方ではなく、渡す材料のほうです。

聴き比べる場のほうを、先にそろえました

キャラクターの声を選ぶとき、候補をいくつも作って順番に再生していました。

ところが、これは判断を誤るんです。作られた音声は、候補ごとに音の大きさが違います。人は大きい音のほうを「良い」と感じやすいので、選んでいるのは声そのものではなく音量です。

そこで、聴き比べ用の音源を作る手順に変えました。候補の音量を同じにそろえて、少し間を空けて1本につなぎます。これを通しで聴けば、条件がそろった状態で比べられます。

直したのは耳ではなく、聴き比べる場のほうです。

人が手で直した配置を、消さない作りにしました

音を動画へ並べる作業も自動化していたのですが、実行するたびに、置いてあるものを一度全部消してから並べ直す作りでした。

つまり、僕が手で微調整した位置が、次の実行で消えます。

なので、すでにあるものには触らず、追加だけする作りへ変えました。僕が手で直した位置は、そのまま残ります。

直したのは自分の手順ではなく、道具の作りのほうです。

4つとも、直っているのは指示文ではなく環境の側です。そしてどれも、AIに説明させて原因が分かってから入れた直しなんですね。

1回作り切ると、何もない状態がどれだけ抜けているか分かります

1から全部作ってみて、標準のままの状態は本当に抜け抜けなんだな、とよく分かりました。

これで完璧、ということでは全然ありません。まだ抜けは多いと思います。それでも、基本的な形はできました。次からはもっと早くできるはずです。

次回また動画を作るとき、僕は今回と同じ間違いをしません。気をつけるからではなく、同じ間違いができない場所を、自分で作ったからです。ここが指示文との決定的な違いだと感じています。

ループエンジニアリングは、このハーネスを自動で回すことです

最後に、もう1つだけ用語の話をさせてください。

GoogleのAddy Osmaniさんが2026年6月7日に書いた記事で、ループエンジニアリングという名前が付きました。

> ループエンジニアリングとは、AIに指示を出す人という役から、自分を降ろすことである。代わりにその役をやる仕組みを、自分で設計する

図は下から順に、プロンプト、コンテキスト、ハーネス、ループです。下ほど手軽で、上へ行くほど効きが長持ちします。指示文を書き直す作業は、いちばん下の段を往復している状態です。

ざっくり言うと、ハーネスを自動で回すのがループエンジニアリングです。

イケハヤさんはこのループを爆速で回していると思われます。だから動画生成もアニメ生成も、とにかく速いです。あのレベルになると、ハーネスはもちろんやったうえで、ループまで組んでいるんだと思います。

ただし、順番があります。ハーネスが整っていない状態でループを回すと、間違いを高速で量産するだけになります。人が見ていないぶん、気づくのが遅れました、では取り返しがつきません。今回の僕で言えば、尺だけ見て通していたあの検品のまま自動で回していたら、おかしな音声が大量に積み上がっていたはずです。

まず、1回の作業が正しく終わる足場を自分で作る。その足場を信用できるようになってから、起動する役を手放す。ループの話は、また別の記事で書きますね。

今からできる、大切な一歩

今日やることを1つだけ挙げるなら、これです。

AIが同じ間違いを2回したら、直させる前に「どこで、なぜ詰まったのか」を説明させてください。そのうえで、証拠を見せてもらってください。

たいてい、そこで本当の原因が出てきます。出てきたら、「いまの解決策をルールにしてください」と頼むだけです。あとはAIが書いてくれます。

言っていることが分からなくても大丈夫です。そのままAIへ依頼すれば、やってくれるでしょう。

大事なのは、その直しが次の作業にも残るかどうか。ここだけ意識してみてください。指示文に書いて終わりだと、明日には消えてしまいますからね。

1つ直せば、あなたはもうそこを通りません。まずは足場から、1つずついきましょう！

メルマガ

元エンジニアがAIについて、実践を元に発信しているメルマガです！ ぜひご登録ください。

健ちゃんのメルマガに登録する

---

出典

• Mitchell Hashimoto「My AI Adoption Journey」（2026-02-05。ハーネスエンジニアリングの初出）

• Addy Osmani「Loop Engineering」（2026-06-07。ループエンジニアリングの初出）

• O'Reilly Radar 転載版（2026-06-22）

こんにちは、健ちゃんです。

Claudeが透かしを入れ始めたというニュースを見て、僕はいくつも仕組みを調べました。

結論から言うと、透かしが入るか入らないかは、正直どうでもいいと僕は思います。本質はコンテンツが面白いかどうかであって、透かしの有無じゃありませんので。と、これで終わってもいいのですが、さすがにそれだと乱暴なので、この記事では、僕がそう考える理由、透かしの仕組み自体も裏付けとして解説していきます。

そもそもテキスト透かしって、何をしているのか

少し調べた人ならご存知と思いますが、「単語の確率分布を操作している」と説明されても、正直ピンときませんよね。僕も最初はそうでした。段階を分けて考えると分かりやすいので、順に見ていきます。

① よくある誤解

「AIの単語選びを全体的に少しだけ歪めて、統計的にバレるようにしている」。これが、多くの人が漠然と持っているイメージだと思います。僕もこの記事を書く前は、そう理解していました。

② Claudeが実際にやっていること

Anthropicの公式ブログを読むと、話はもう少し繊細です。透かしがかかるのは、単語すべてではありません。「どちらを選んでも意味が変わらない場面」だけなんです。

たとえば「天気は寒く、空は＿」の続きが「曇り」でも「灰色」でも、文の意味は変わりません。こういう、答えが1つに決まらない選択肢が並んだときにだけ、秘密鍵と直前の単語列を使って、どちらを選ぶかに軽い偏りをかけます。コードや事実の記述のように「答えが実質1つしかない場面」には、そもそも透かしがかかりません。読者には、透かしありの文章と透かしなしの文章の区別がつかないともAnthropicは説明しています。

③ 研究が向かっている先

ここから先はClaudeの現状ではなく、研究の話です。学術論文（SemStamp、PASA）では、単語1つずつを狙うのではなく、文全体の「意味のかたまり」をあらかじめ地図のように領域分けし、生成した文がどの領域に落ちるかで判定する方式が提案されています。文の意味は言い換えても変わらないので、表面の単語が総取り替えになっても透かしが残りやすい、という発想です。

具体的には、こんなイメージです。「今日は寒いですね」と「本日は肌寒いです」は、単語がまるで違っても、ほぼ同じ意味を表していますよね。この2つの文を、あらかじめ地図上の同じ「区画」へ置いておく。逆に「今日は暑いですね」は意味が違うので、別の区画です。生成した文がどの区画に落ちたかだけを見れば、途中で単語がそっくり入れ替わっても、区画そのものは動かないので透かしが残ります。

つまり流れとしては、①「単語をランダムに歪める」という粗い理解から、②「同じ意味を持つ単語同士でだけ偏りをかける」という実際の仕組みへ、そして研究レベルでは③「単語ではなく文の意味そのものを領域として扱う」方向へ進んでいる。単語の確率をいじる話から、意味のかたまりの確率をいじる話へ、というのが仕組みの変化です。

その区画に入るまで、AIは何をしているのか

ここで1つ、気になることが出てきます。文全体を「有効な区画」に入れるって、内容を書き換えているということなのでは？

結論は「いいえ」です。区画に入るまでAIがやっているのは、内容を変えることではなく、同じ内容の言い方を何度も出し直すことなんです。

「空は曇りです」も「空は灰色です」も「今日は曇っていますね」も、AIが普通に出しそうな言い方の候補です。この中から1つを選ぶとき、AIはまず候補をいつも通りに出し、その候補が有効区画に入っているかを確認し、入っていなければまた出し直す。これを繰り返します。SemStampの論文によれば、有効な1文を見つけるのに、平均で13.8回も候補を出し直しているそうです。単語1つをどちらか選ぶだけの②と比べると、③はかなり粘って「欲しい言い方」を探していることになります。

ここまで引き直せば、内容自体は変わりません。ですが、AIが真っ先に選びたかった、いちばん自然な言い方とは限らなくなります。

普段AIが文章を書くとき、その場その場でいちばん出てきやすい言い回しには、「こういう文脈なら、普通こう続ける」という暗黙の型が乗っています。これが本来の生起確率です。13回も引き直して、たまたま有効区画に入った14回目の言い方は、その型からわずかにズレたものかもしれません。1文だけならまず気づきませんが、こういう選び直しが何十文と積み重なると、論理は通っているのに、どこか据わりの悪い文章になっていく可能性は否定できません。

研究側もこの点は意識していて、境界ギリギリの候補は捨てる、困惑度（文章としての自然さの指標）を計測して透かしなしと同水準に保つ、といった対策をしています。実際、単文レベルの自然さはほぼ同等という報告もあります。ただし、段落全体の流れや一貫性まで厳密に測る指標は、論文の中でも示されていません。「粘って選んだ言い方の積み重ねが、文章全体の据わりにどう効くか」は、今のところ検証されていない領域だと言えます。

区画に落とし込む文章を整形するまでガチャを回し続けるので、その分だけ計算コストがかさむんですね。Claudeが今のところ単語レベルの透かしまでしか実装していないのは、たぶんこのコストが理由なんじゃないかと、僕は見ています。ここは僕の推測で、Anthropicが明言しているわけではありません。

なぜ今、透かしなのか

Anthropicがこれを始めたのは2026年8月11日です。理由は単純で、EU AI法の透明性コードが8月2日に発効し、AI企業に生成コンテンツへの標識づけを義務づけたからなんです。対象はClaude API、Claude Code、Claude Coworkなど幅広い製品に及びます。

透かしを持つ側、つまりAnthropicは、専用の鍵を使って「この文章がClaudeの透かしを持った選び方に一致しているか」を確認できます。一致度が高いほど、Claude生成の可能性が高いと判定される仕組みです。

透かしの有無より、面白いかどうかが本質です

透かしにも、統計的な精度の限界があります。Zennで公開されている検証記事によれば、俳句のような短文は信号を積み上げるための長さが足りず、検出が困難です。賢くない小型モデルにリライトだけさせると、透かしの元になった単語選びごと消えてしまうという指摘もあります。本気で消したい人は、すり抜ける方法をいくつも持っているということです。

けれど、僕が本当に言いたいのはそこじゃありません。

透かしが入るからといって、AIを使わない方向には向かわないと思っています。AIで文章を作る力と、自分で手打ちする力を比べると、パフォーマンスは10倍、20倍も違うんです。文章の上手い人が手打ちすれば質は勝つでしょうが、それはそもそも比較の土俵が違う話でしょう。

問題は、そこから先です。AIがそのまま吐き出した記事って、検索してまとめましたね、ぐらいの文章にしかならないんですよ。それだと誰も読まないんです。誰がやっても同じものが作れるわけですから。そういう文章には透かしのある無しに関わらず、もう価値がありません。

だから僕は、透かしを消すツールを使う・使わないみたいな話は、正直レベルの低い話だと思っています。本質は、どうやったら面白いコンテンツを生み出せるか、その一点なんですよね。構成を工夫する、ネタをタイムリーに合わせる、自分の声や意見を混ぜ込む。これができれば記事は面白くなりますし、これができなければAIを使おうが使うまいが面白くなりません。つまり、面白さはAIを使う・使わないとは関係のない、発信者の努力の話なんです。

検索エンジンやAIの学習が「透かし付き＝AI生成だから」という理由だけでコンテンツを除外していったら、世の中のコンテンツはほぼ無くなると思います。人間が手で書いた記事だけが残ったとしても、それはそれで幅の狭い世界になるだけで、面白いかどうかとは別の話です。なので、僕はここをそこまで心配していません。

もちろん、手書きのほうが質が高いに決まっている場面はあります。僕自身、最近もAIに文章を書かせていますが、正直不自然で読みにくい箇所がまだたくさん出てきます。それを僕がちょこちょこ直しているのが実情です。AIに任せて最初から面白い文章が出てくるわけではなく、使い手が鍛えないと面白くならないレベルのものなんです。そこをどう面白くしていくかが、人間の工夫のしどころではないでしょうか。

実例、僕は前日の記事をこう組み立て直しました

「言うだけなら簡単でしょ」と思われそうなので、僕がやった具体例を1つ出します。

前日、米国のゲーム業界でAIを使って作られたゲームはレビュー数が半減する、という調査結果を扱った記事がありました。最初はAIがまとめたリサーチ記事のまま出そうかと思っていたんです。ですが、自分で読み返してみて、率直に「これ、全然面白くない」と思いました。

そこで、自分の考えを混ぜ込んで、僕の主張を軸に記事を組み立て直しました。調査結果という事実は残したまま、自分の見解を核に据え直した形です。事実と自分の意見、両方が入った記事になりました。

この記事もClaudeで生成しているので、AI判定にはおそらく引っかかります。ですが、それと記事が面白いかどうかは、まったく別の話なんです。先日の記事はこちらにありますので、よかったら参考にしてください。

生成AIゲームはレビューが52.6%減る？Steam調査と個人開発者が恐れなくていい理由

AI判定に引っかかりたくないからと自分で全部手打ちする人がいたとしても、構成を面白くする工夫まで手抜きになってしまえば、透かしがあってもなくてもつまらない記事になってしまいます。順番が逆なんですよね。

今からできる、大切な一歩

最後に、今日のうちにできることを1つだけ。

AIがそのまま出した下書きを、あなた自身が読み返して「面白い」と思えるか、一度確かめてみてください。 面白くないと感じたら、透かしを気にする前に、例えば自分の主張や声を文章に取り入れるなど、少しでも面白くなる工夫をしてみてください。

透かしが入っているかどうかは、正直どうでもいいことです。読者が最後まで読んで、面白かったと思ってくれるかどうか。そこに時間とエネルギーを使うほうが、ずっと意味があると思っています。

AIで作る方法は、僕のメルマガで

AIをどう使い、どう面白くしていくか。僕が実際に考えて動いた記録は「一忍メルマガ（健ちゃんのメルマガ）」でお届けしています。企画の立て方、プロトタイプの作り方、AIへの任せ方まで、実践から得た話を一話ずつお伝えしています。

一忍メルマガ（健ちゃんのメルマガ）に登録する

---

出典

• Anthropic公式「How Claude's text watermarking works」

• TechCrunch「Anthropic says it will watermark text generated by its AI models」（2026-08-11）

• TechCrunch「Some Claude users are mad that Anthropic's new watermarks will catch them cheating at their jobs, classes」（2026-08-13）

• TechCrunch「Anthropic shares more details about how Claude's new watermarks will work」（2026-08-16）

• Zenn「Claudeのテキスト透かしは、何を守れないのか」

• Zenn「AI使用を100%公言している個人開発者が検査を1本だけ足した話」

• Hacker News寄稿「Text AI watermarks will always be trivial to remove」

• SemStamp（arXiv 2310.03991）

• PASA（arXiv 2605.10977）

• イラスト内キャラクター「シャオラン」: CryptoNinjaファンアート（ファウンダー: イケハヤ／デザイン: Rii2）

こんにちは、健ちゃんです。

生成AIの利用を開示したゲームは、初月のレビューが52.6%減る。

この数字を見たとき、僕も「AIでゲームを作るのは危ないのでは」と思いました。実際、米国では生成AIを使わない条項を契約へ入れる動きも出ています。

でも、今日のスペースで話しながら、僕の考えははっきりしました。

過去の数字に、未来の選択まで引きずられてはいけない。

52.6%減という数字は無視してはいけません。ただし、これは「AIを使うな」という結論ではなく、AIを使うときに越えるべき課題を示した数字です。

特に個人は、AIへの批判を恐れて作ることを諦めるより、権利と品質に向き合いながらAIを使い、これまで作れなかったものを形にしたほうがいい。この記事では、その理由を整理します。

52.6%減は、無視できない事実です

ゲーム市場を分析するGame Oracleは、2025年にSteamで発売された商用ゲーム9,879本を調べました。

同じジャンル、パブリッシャーの有無、開発経験、発売月などの条件を揃えて比較すると、生成AIの利用を開示したゲームは、初月レビューが52.6%少ないという結果でした。

| 項目 | 中身 | |---|---| | 対象 | Steamで2025年1〜10月に出た商用ゲーム9,879本 | | AI開示の割合 | 17.9% | | 初月レビュー | 同条件のゲームより52.6%減 | | レビュー数の中央値 | AIなし7件 / AIあり4件 |

ただし、この調査が測っているのはレビュー数です。売上そのものではありません。レビュー数を売上の代理指標として使った推計なので、「AIを使うと売上が必ず52.6%減る」とは言えません。

それでも、企業が警戒するのは当然です。ゲーム業界の弁護士Haley MacLeanさんによると、クライアントのほぼ全員が、生成AIを使わない条項を契約へ入れるようになったそうです。プレイヤーの反発と著作権リスクを避けるためです。

ここまでは、企業がAIを避ける理由として筋が通っています。

でも、AIを禁止すれば生き残れるのでしょうか

僕が引っかかったのは、ここです。

ゲーム開発の費用は上がり続けています。帝国データバンクによると、スマホゲーム事業者の倒産は2026年1〜7月で10件。2025年の年間3件を、7か月ですでに上回りました。主な背景として挙げられているのは、数億円規模に膨らむ初期開発費と、リリース後の運営費です。

つまり企業は、二つの問題に挟まれています。

• AIを使えば、反発を受けてレビューを失うかもしれない

• AIを使わなければ、高い開発費と長い制作期間を抱え続ける

ここで「過去に数字が悪かったから、AIは禁止する」と決めるだけでは、費用の問題は残ったままです。むしろ新しい生産手段を自分で封じ、手足を縛ることになりかねません。

いちばん危ないのは、中途半端に使うことです

企業にとって最も苦しいのは、AIを少しだけ試験導入する状態ではないかと推測します。

一部にAIを使っただけでも、利用を開示すればプレイヤーには「AIを使ったゲーム」と見えます。一方、導入範囲が小さければ、学習や検証の費用が先に立ち、十分なコスト削減にはなりません。

反発は受けるのに、生産性はあまり上がらない。

これでは割に合いません。

AIを使うなら、単なる安上がりな代替品としてではなく、人間が品質を管理しながら制作工程そのものを組み替える必要があります。自社IPや利用条件の明確な素材を使い、AIで生まれた時間と予算を、遊びの面白さや仕上げに戻す。その結果として、従来より面白いゲームを出せるかが勝負です。

過去の数字は、この挑戦をやめる理由ではありません。どこを改善すべきかを教える警告だと僕は捉えています。

個人は、失うものより得られるものが大きい

そして、僕が最も伝えたいことがこれです。個人がAIを使うと、得られるもののほうが大きい、ということです。

同じGame Oracleの調査では、AIによる悪影響はすべての開発者へ同じように出ていません。

• 経験の浅い開発者では、AI利用による明確な悪影響がほとんど見られない

• 実績のあるスタジオでは、レビュー数を代理指標とした販売実績の推計が40〜60%低い

大手には、守るべきブランド、既存ファン、契約があります。だからAIを使ったときに失うものが大きい。

一方、無名の個人は、そもそも認知が少なく、失うレビューやブランドも多くありません。

だから個人にとっては、AIを使うリスクより、AIを使わず何も作れないまま終わるリスクのほうが大きいと僕は思います。

僕自身、AIを使わずにゲームを作れと言われたら、現実的には無理です。イラスト、動画、プログラムをすべて外注する資金もありません。AIがあるから、一人でもゲームを形にし、実際に遊んでもらうところまで進められているわけです。

個人の勝負は、AIの有無ではなく面白さです

もちろん、AIを使えば何でも許されるわけではありません。

文化庁の整理では、AI生成物の著作物性は、指示・入力の内容、生成の試行、複数案からの選択、人間による加筆・修正などを踏まえて個別に判断されます。既存作品の権利を侵害しないことも大前提です。

だから僕は、二次創作や商用利用の条件が明確なCryptoNinjaやCNPを題材にし、人間が選び、直し、組み上げる工程を重ねています。

守るべき線を守ったうえで、最後に問われるのは「AIを使ったか」だけではなく、遊んで面白いかどうかです。

AIで作ったという先入観から、厳しく見られることはあるでしょう。だからこそ、批判を打ち消すほど面白いものを出す。AIで浮いた時間を、企画、テスト、演出、改善へ戻す。僕はそこへ進みたいです。

それでもあなたは、過去にしがみつきますか？

52.6%減という数字は事実です。契約や著作権のリスクも確かにあります。

でも、その事実から「AIは使わない」とだけ結論づけるのは、過去に引きずられた意思決定です。

リスクを知ったうえで、「未来に向けて」どうすればAIでもっと面白いものを作れるかを考える。

企業にも必要な姿勢だと思いますが、特に失うものがまだ少ない個人こそ、未来側へ踏み出す勇気が必要だと僕は思うのです。AIを使って作り、公開し、遊んでもらい、改善する。その経験は、作らなければ得られません。

個人の課題は、AIを使うかどうかで立ち止まることではなく、作ったものをどう面白くし、どう見つけてもらうかです。

今からできる、大切な一歩

まずは、好きなキャラクターの絵を1枚、動かしてみてください。

ゲームを1本作るのは重くても、キャラクターが1体動くだけで、「自分にも作れる」という感覚が生まれます。僕もここから始めました。

その手順は「2Dキャラモーション作成スキル」としてまとめ、一忍メルマガへ登録いただいた方へお渡ししています。1枚の絵を分解し、動くキャラクターとしてアプリへ組み込むまでの道順です。

メルマガ登録特典を受け取る

過去の数字を知ったうえで、未来の一作を始めましょう。

---

出典

• X Space「米国ゲーム業界に見る、AIに足を引っ張られる大手と、自由な個人 #1241」 2026年8月20日

• Game Oracle, Ross Burton「AI in Games: The Impact On Sales」 2025年12月17日

• GamesRadar+（Haley MacLeanさんへのインタビュー） 2026年8月

• 帝国データバンク「スマホゲーム事業者の倒産動向（2026年1-7月）」 2026年8月8日

• 文化庁「AIと著作権について」

こんにちは、健ちゃんです。

7月に「AIの“モデル”と“ハーネス”は別物です」という記事を書きました。Claude Codeという操作環境（ハーネス）の中身のエンジンを、別のAIモデルへ載せ替えてみた話です。あのときの結論は「面白いけれど不安定」でした。

理由ははっきりしていて、ローカルにプロキシサーバーを立てて、その中継を通していたからです。やり取りが一段増えるぶん、不安定になっていました。

ただ、これは載せ替えという発想そのものの限界ではなく、相手の選び方の問題なんですよね。

前回積んだのはGPT系のモデルです。あちらにAnthropic互換の入口はないので、中継役を挟むしかありません。一方でDeepSeekとKimiは、もともと公式にAnthropic互換のエンドポイントを持っています。DeepSeekは2025年8月のV3.1から、KimiもK2の頃から用意していました。つまり最近できた抜け道ではなく、1年ほど前からある正面の入口です。

この入口を使えば、中継役がいりません。

そこで今回は、載せ替えて終わりにせず、普段やっている仕事をそのまま1本、丸ごと投げてみました。

載せ替えは5分で終わります

やることは環境変数を3つ渡すだけです。接続先のURL、APIキー、使うモデル名。これをClaude Codeの起動時に渡すと、画面はいつものClaude Code、頭の中身だけが別のAIという状態になります。

僕は毎回打つのが面倒なので、claude-altという小さな起動スクリプトを作りました。claude-alt deepseekと打てばDeepSeek、claude-alt kimiと打てばKimiで立ち上がります。

ここで1つだけ気をつけたことがあります。環境変数を、起動したそのプロセスの中だけで閉じることです。シェル全体に設定してしまうと、普段のclaudeまで巻き添えで別のAIになってしまいます。仕事道具を壊さないための線引きですね。なので、専用のCLIかエイリアスを用意しておくのがお勧めです。僕もそうしています。言っていることが分からなくても大丈夫です。AIにそうしてと依頼すれば、やってくれるでしょう。

設定値は以下の公式サイトも参考にしてください。

• DeepSeek公式ドキュメント「Integrate with Claude Code」

• Kimi公式ドキュメント「Use Kimi in Claude Code」

つまずいたのは2か所だけ。でも特徴が正反対でした

素直に動いた、と言いたいところですが、2か所ひっかかりました。この2つは、これから試す人がほぼ確実に踏むので先に置いておきます。

1つ目はKimiです。公式ドキュメントに書いてあるモデル名を指定したら、404 Not found the modelが返ってきました。キーが無効なら401のはずなので、認証は通っていて、モデル名だけが違う。実際にアカウントで使えるモデルの一覧をAPIへ聞きに行くと、ドキュメントの表記とは違う名前が並んでいて、API経由のモデル名へ直したら動作しました。

2つ目はDeepSeekです。存在しないモデル名を渡しても、エラーになりません。警告が1行出るだけで、そのまま下位のモデルへ差し替えられて動きます。

同じ「モデル名が違う」でも、片方は止まって教えてくれて、もう片方は黙って別のもので走る。気づかないまま「速いけど品質が微妙だな」と誤解するのは、後者のほうです。起動時の警告行は読み飛ばさないほうがいいですね。

実務を1本、ゼロから投げてみました

ここからが本題です。普段の仕事でパフォーマンスを見てみました。

課題は「Substackの週次レポートを1本作る」です。手元の計測データベースから直近7日ぶんを集計し、記事ごとの数字と購読者の推移を表にして、傾向を3つ以内でまとめる。データが無い期間は「取れない」と書き、推測で埋めない。出典のスナップショットIDと集計方法を末尾に書く。指示書はこれだけです。

DeepSeekは、こう動きました。

まずデータの置き場所をCLIに聞き、保存形式を1行だけ読んで構造を把握し、7日ぶんを取り出す。ここで出力がツールの上限を超えたのですが、ハーネスが結果を自動でファイルへ逃がしてくれたので、それを読み直して続行しました。あとは集計スクリプトを書いて実行し、レポートを書き上げる。

所要5分00秒、レポートは実際のマーケ資料の置き場所へ出力されました。

次いで、別のスクリプトでデータベースから計算し直して照合しました。日次7行、記事5行、notes10行、冒頭のサマリまで全部です。

結果は一致しました。

仕上がりへの不満はありません。データが欠けている箇所も、勝手に埋めずに「この日以降APIから値が来ていない」と書いてありました。DeepSeekさん、この手の仕事ならそつなくこなしてくれるようです。

使ってみて分かった、3つの壁

一方で、本番の主力にするには壁があります。

1つ目は画像です。 DeepSeekに画像を読ませると[Unsupported Image]が返ります。これは推測ではなく、実際に1枚渡して確認しました。僕の仕事は生成した絵やサムネイルを目で確かめる工程が多いので、ここが効きます。ちなみに同じ画像をKimiは読めました。文字も、描かれている人物のポーズも正しく答えます。この1点だけならKimiに軍配が上がります。

2つ目はコンテキストの狭さです。 長い作業をずっと続ける用途には向きません。話が積み上がるほど苦しくなります。

3つ目は短時間のレート制限です。 体感では、並行して走らせられるのは3つあたりが限界でした。何本も同時に仕事をさせる使い方とは相性がよくありません。

なお、Kimiでも同じ実務課題を回すつもりでしたが、本番のタスク実行でAPI呼び出しが通らず、比較は完成していません。ここは未確認のまま置きます。

そして、請求画面を見ました

いちばん伝えたいのはここです。

この日、検証にAPIを使ったのはだいたい1時間ほど。その利用画面がこれです。

• 金額: $3.61

• APIリクエスト: 260回

• トークン: 26,296,019

1時間で26,296,019トークンです。桁を見間違えていません。260回のやり取りで、1回あたり平均10万トークンが動いています。ちなみに、上の検証タスク以外のタスクも並列実行していたので、上記タスクだけではないことを付け加えておきます。

なぜこうなるのか。ハーネスは、毎回のやり取りでそれまでの文脈を丸ごと送り直すからです。人間がチャット画面で会話するのとはトークンの消え方がまるで違います。ファイルを読めばその中身が乗り、コマンドを叩けばその出力が乗り、それが次のターンでもまた乗る。従量課金と、この使い方の相性がよくないのです。

金額そのものは、1時間3.61ドルなら安いと感じるかもしれません。ですが単純に伸ばすと、1日8時間で約29ドル、月20日で約580ドルになります。もちろん使い方次第で上下しますし、僕の1時間がそのまま毎日続くわけでもありません。それでも「気軽に試す額」と「毎日の仕事道具の額」はまったく別の話だと分かります。

ここで比較対象になるのがcodexです。codexは定額のプランに含まれていて、使い込んでも請求が伸びません。一晩中まわしても、朝に請求画面を開いて青ざめることがない。

つまり、ガチで毎日使うなら、コスパはcodexのほうが圧倒的に高いというのが今回の結論です。

それでも、載せ替えを試す価値はあります

否定しているように読めるかもしれませんが、そうではありません。

今回いちばんの収穫は、Claude Codeという操作環境そのものが、エンジンを替えても崩れなかったことです。出力が上限を超えたときの逃がし方も、ファイルの読み書きも、コマンド実行も、全部いつもどおりに動きました。5分でレポートが1本仕上がり、その数字が機械照合を通ったという事実は重要です。

前回「面白いけれど不安定」と書いた部分は、プロキシが消えたことでほぼ解消しました。残っているのは、モデル側の得意・不得意と、料金の仕組みの話です。

だからおすすめの使い分けは、こうなります。毎日の主力はClaudeやCodexの定額サブスクで回す。そのうえで、サブスク枠も使い切って短時間だけ動かしたいときに、使ってみるのがいいと思います。

今日できる、小さな一歩

最後に、今日のうちにできることを1つだけ。

あなたが今使っているAIの、利用状況の画面を開いてみてください。

定額のプランなら、今月どれだけ使ったか。APIなら、いくら請求が立っているか。それだけです。設定も登録もいりません。

数字を見ると、「なんとなく便利」だった道具が、はじめて「1時間いくらの道具」に変わります。そうなると、どの仕事を任せて、どの仕事は自分でやるのかが、驚くほどはっきり見えてきます。

僕は今日、その画面を見て手が止まりました。止まったおかげで、使い分けが決まりました。あなたもぜひ、一度開いてみてください！

編集後記

今回いちばん効いたのは、記事を書くことそのものより、請求画面を開いたことでした。

道具の値段は、契約したときに一度だけ見ます。でも、使い方の値段は、開かないと一生見えません。僕はこの1年、AIの利用画面をほとんど開いていませんでした。開いてみたら、自分がどれだけ雑に道具を使っていたかが数字で出てきて、少し背筋が伸びました。

今日から、週に一度は開こうと思います！

メルマガ

元エンジニアがAIについて、実践を元に発信しているメルマガです！ ぜひご登録ください。

一忍メルマガ（健ちゃんのメルマガ）に登録する

こんにちは、健ちゃんです。

3Dキャラクターを動かすとき、人体モデルの制作も（凝ると）大変ではあるんですが、実はモーション（人体の動き）も結構大変なんですよ。立ち姿までは作れても、回し蹴りや宙返りは自分の体では再現できませんよね。

かといって、モーションキャプチャのスタジオは1時間あたり1万円から3万円ほど。アクター代は別に発生しますし、1時間で必要なモーションを全部撮り切れるはずもありません。個人にとっては、正直なところ高値の花です。

そこへ「文章を書くだけで3Dモーションが返ってくる」サービスが育ってきました。text to motion、略してTTMと呼ばれる分野です。

そこで、代表的な4つへまったく同じプロンプトを渡して、返ってきたモーションを並べてみました。結論から言うと、いま選ぶならUthanaの3.0です。

そして今回いちばん驚いたのは2位でした。無料で公開されているオープンなモデル、HY-Motion 1.0です。商用サービスのQuickMagicを、指示の守り具合で上回りました。

4つに、まったく同じプロンプトを渡しました

プロンプトはこれです。

A master of Chinese martial arts performs a flowing two-hit roundhouse kick combo. Start from a compact guarded stance with knees bent and elbows tucked in. Execute one powerful right-leg spinning roundhouse kick, land smoothly with balance and control, then immediately transition into one powerful left-leg spinning roundhouse kick. Use each leg only once: right kick, then left kick, with no repeated kick from the same leg. Emphasize fluid weight transfer, hip rotation, precise footwork, strong balance, and seamless motion. The movement should feel fast, disciplined, rhythmic, and highly skilled.

中国武術の使い手が、右足の回し蹴りから左足の回し蹴りへ連続で入る。同じ足を2回使わない。着地は崩さない。ざっとこういうプロンプトです。

わざわざ「同じ足を2回使わない」と念を押しました。この手の条件こそ、生成AIが真っ先に取りこぼすところだからです。プロンプトの守り具合が、そのまま実力の差になって出ます。

Uthana 3.0

画面が2つに割れているのは、1回のプロンプトで2本返ってくるからです。左が「Show motion 1」、右が「Show motion 2」。同じ注文への、別々の答えですね。

まず右を見てください。構えから回し蹴り、着地して構えへ戻り、もう一度回し蹴り。2発入って、そのあいだ体幹が落ち着いています。

しかも、1発目と2発目で蹴る脚がきちんと入れ替わっています。「同じ足を2回使わない」という条件まで通したのは、今回の4つでUthanaだけでした。

ところが左は、構えたまま手を下ろして、あとは直立したまま終わります。蹴りが一度も出ません。

同じプロンプト、同じ料金で、この差なんです。いい出目が1本混じっていれば勝ち。そういう道具だと思って回すことになります。

HY-Motion 1.0（Tencent / オープンモデル）

構えから回し蹴り、着地、構えへ戻り、もう一度回し蹴り。2発入りました。 着地も崩れていません。無料で公開されているモデルが、です。

ただし、惜しいところがあります。2発とも右足なんです。

FBXの骨から足首の高さを拾って測ったところ、1発目が24〜48フレーム、2発目が84〜112フレーム。どちらも右足首だけが1.3mを超えて上がっていました。左足は最後まで床の近くにいます。つまり「同じ足を2回使わない」という条件は、まるごと無視されたわけです。

左右の入れ替えまで通したUthanaには、ここだけ一歩及びません。とはいえ、連続で2発を蹴り、そのあいだ構えを保つところまでは来ています。オープンなモデルでここまで出るとは思っていませんでした。詳しい話は記事の後半でまとめます。

QuickMagic

蹴りは出ました。ところが1発だけなんです。

生成された10秒のうち、前半で1回蹴ったあとは、残りをほぼ構えたまま立って過ごしています。コマ送りで数えたところ、118フレーム中で蹴っているのは21〜29フレーム付近だけ。40フレーム以降は、ほとんど動きがありませんでした。

「2発」も「左右を入れ替える」も通っていないわけです。とはいえ蹴り自体の形は素直で、破綻はしていません。

Rokoko

こちらは、武術に見えませんでした。今回の4つでは、いちばん厳しい結果です。

ただ、これはRokokoが弱いという話ではないと思っています。Rokoko自身がテキストからのモーション生成を「プロトタイプやブロッキング、アニメーションの隙間を埋める用途」と説明しているんです。つまり、決め技を作らせる道具ではない。狙いが違うものへ武術のプロンプトを出した、こちらの問題でもあります。

Uthanaが個人の制作に向いている理由

さて、勝ち残ったUthanaの話をさせてください。良かったのは出来上がりだけではないんです。

1) 公式APIが揃っています

text to motionもvideo to motionも、APIから呼べます。3.0はジョブを投げてポーリングする非同期方式で、出力はFBXとGLB、フレームレートは24・30・60から選べる仕様です。つまり、AIパイプラインへそのまま組み込めます。手作業でポチポチする道具ではなく、部品として扱えるわけですね。

2) 自分のキャラクターへ合わせてくれます（retargeting）

自作モデルをアップロードすると、そのキャラクターに合わせたモーションが返ってきます。同じ「歩く」でも、体格が違えば歩幅も腕の振りも変わりますよね。そこを吸収してくれるのは、地味ですがありがたいところです。

3) 足が滑りにくい（foot IK）

IKはInverse Kinematicsの略で、「足はここに着く」と先に決めてから、膝や腰の角度を逆算する考え方のことです。これが標準で使えるので、地面を滑る不自然な歩きが出にくくなります。

4) モーション同士をつなぐstitchがあります

stitchは、モーションからモーションへの遷移そのものを生成する機能です。

たとえば歩いている状態から蹴りに入る場合、蹴る側の足が前に出ていたら、いったん後ろへ引いて構え直す必要がありますよね。この「引いて構え直す」動きを、blend treeの中間補間だけで作ると、どうしてもぎこちなくなります。そこで、歩き→蹴りの遷移をAIに生成させてしまおう、というのがstitchの発想です。

そのstitchを試したら、（今回は）うまくいきませんでした

走りから蹴りへ、stitchでつないでみました。

結果は、走りが途中で失速して直立に戻り、そこから体をひねったところで終わってしまいました。肝心の蹴りが出ていません。狙った遷移にはならなかったわけです。

しかし、機能として既に載っているという事実のほうが、僕には大きく見えました。TTM本体の品質がこの1年で実用ラインに乗ったことを考えると、stitchも同じ道をたどる可能性が高いからです。ここは今後に注目しておきたいところ。

そしてもう一つ、大事なことがあります。3Dモーションもガチャです。 冒頭のUthanaで、同じプロンプトから返った2本のうち1本がまるで動かなかったのを見ましたよね。あれが普通です。

他の生成AIと同じで、少しの違和感は受け入れて、手直ししながら使うほうが結果的に早いんです。何度か引き直せば良い出目は来ますが、完璧を最初から求めるのは、やはり無理があります。モーションはBlenderで編集できますから、大枠が決まったら細部は手元で直す。現状はそれくらいのノリでちょうどいいと思います。

料金は、スタジオモーキャプと桁がひとつ違います

Uthanaには従量課金（Pay-as-you-go）が用意されています。主なものを並べます。

3.0は$0.10/秒。8秒のモーションで$0.80ですから、日本円にして120円ぐらいです。

この数字が高いのか安いのか、単体ではピンと来ませんよね。そこで冒頭のスタジオ料金と並べてみます。1時間1万円から3万円、プラスでアクター代。桁がひとつどころではありません。品質がこのまま上がっていけば、モーキャプ市場の地図はかなり書き換わるはずです。

ところで、料金ページには「$100/mo minimum commitment」という表記も並んでいます。これを「従量課金を使うには毎月100ドル払わないといけない」と読むと、間違いなんです。

実際はサポートの段階を表す列でした。全プランがDiscordサポート、月100ドル以上のコミットでメールサポートと新機能の先行アクセス、Enterpriseで優先サポートとSlack、専用GPUまで。従量課金そのものは、公式の言葉どおり「すべてのモデルと機能」で使えます。

月額プランのほうも並べておきます。無料のDreamerは生成が無制限でダウンロードが月30秒ぶん、APIとSDKも触れます（非商用ライセンス）。以降は月$10のIndieが75秒、$16のCreatorが150秒で商用可、$50のProが500秒、$160のBuilderが2,000秒と続きます。

さて、ここが料金表でいちばん見落としやすいところです。

この「何秒」は、生成できる秒数ではありません。ダウンロードできる秒数です。

無料のDreamerプランにも「Unlimited motion generation」と書かれているとおり、作って画面で確かめるところまでは無制限なんです。秒数が減るのは、できあがったモーションを手元へ落とす瞬間だけ。

これが分かると、試し方が変わりますね。プロンプトを何十回でも書き直して、画面で見て、納得した1本だけを落とせばいい。ガチャを引く回数ではなく、当たりを持ち帰る回数で課金される仕組みなんです。「月75秒しかないから慎重に」と身構える必要はありません。

というわけで、個人が始めるなら無料か月$10から。まずはここで手触りを確かめるのがいいですよ。

自分で演じられる動きなら、QuickMagicが効きます

AIに聞いたところ、QuickMagicは映像からのモーキャプ（video to motion）に強いとのこと。ほんまか、ということで自分で撮って試しました。

物を拾う

しゃがんで拾って立ち上がる。ひとつの動作として、素直に取れていますね。

ダンス

ぎこちないのは僕のせいです。すいませんw

体ごとの回転

これは驚きました。正面から横、背中、また横、正面と一周するあいだ、キャラクターの向きが破綻しません。単眼のカメラだと体の裏側は見えていないはずなのに、ちゃんと回してくるんです。

可能性を感じますね。定位置のダンスはモーキャプで撮り、ステージ上の移動はTTMで作って、うまくつなぐ。そんな合わせ技も使えそうですね！

今日時点の、僕の使い分け

以上を踏まえると、運用はこう整理できます。

分かれ目は、その動きを自分で演じられるかどうかです。

短い動作、危険な動作、自分にはできない動作はTTMへ。長めのダンスや、自分の癖を残したい芝居はスマホで撮ってモーキャプへ。どちらもBlenderで受けて、必要なところだけIKを直し、GLBで書き出してゲームエンジンへ渡すことができます。

そのHY-Motion 1.0を、どこで動かすか

最後に、手元で動かせる側の話を。

いま注目しているのは、Tencentが公開したHY-Motion 1.0です。Diffusion Transformerとflow matchingで組まれた10億パラメータ規模のTTMモデルで、コードもモデルもGitHubとHugging Faceで公開されています。学習は三段構え。3,000時間超のモーションデータで事前学習し、400時間の高品質データで微調整、最後に人手の評価で物理的な自然さを詰めたそうです。4.6億パラメータの軽量版（Lite）もあります。

冒頭に置いた映像は、この標準版（10億パラメータ）の出力です。FBXで返ってくるので、Blenderへ読み込んでそのまま焼きました。

軽量版のLiteも同じプロンプトで回しています。

蹴りの数は出ますが、体幹が暴れて着地が落ち着きません。足首の高さを測ると1.69mまで跳ね上がっていて、標準版の1.39mより明らかに大振りです。ちなみにこちらも2発とも右足でした。パラメータ数の差が、そのまま安定感の差になって見えます。

ただし、手元のGPUではまだ動きませんでした

では今すぐローカルへ移せるかというと、そこは別の話でした。

公式が出しているVRAMの下限は、標準版で26GB、Lite版でも24GB。テキストの読み取りにQwen3-8Bを積むためで、ここが重いんです。無料のGoogle Colabは16GBのT4ですから、この時点で入りません。

そこで今回は、RunPodで48GBのGPU（L40S）を1時間$0.99で借りて回しました。生成そのものは2本で33秒。ところが、そこへ辿り着くまでの環境構築で1時間近く溶かしています。pipが弾かれ、ライブラリのバージョンが噛み合わず、モデルの重み25GBを落として、という往復です。

結論として、いちばん安く速かったのはfal経由でした。 同じHY-Motion 1.0が1生成$0.08、つまり12円ほど。10秒で返ってきます。記事に載せた2本の映像も、最終的にはこちらで作りました。

「オープンなモデル＝自分のPCで動かす」と考えがちですが、いまはオープンなモデルを、誰かのGPUで安く借りて使うという中間の道がいちばん現実的なんです。ローカルで完結させるのは、24GB超のGPUが手元に来てからでいいと思います。

まとめ

• TTMは実用段階へ入りました。商用サービスの一押しはUthana 3.0です

• 映像からのモーキャプはQuickMagic。自分で演じられる動きは、こちらが速い

• オープンなHY-Motion 1.0が蹴りを2発出しました。ただし2発とも右足で、左右の指示は無視されています

• ただしVRAMの下限は24GB超。手元のPCではなく、falのような従量課金で借りるのが現実的です

• 精度はまだ粗いので、Blenderで補正しながら使いましょう

モーションが作れないから3Dを諦める、という時代はもう終わりました。文章と、スマホのカメラと、Blender。この3つで足りるんです！

編集後記

今回いちばん面白かったのは、失敗したstitchでした。

走りから蹴りへの遷移という、人間なら何も考えずにやっていることが、AIには難しい。逆に言えば、僕たちが「当たり前」として飛ばしている動きの中に、まだ手つかずの領域が残っているということです。

道具の進歩を待つのも大事ですが、待っているあいだに手を動かした人だけが、道具が揃った瞬間に走り出せます。今日も1本、作っていきます！

メルマガ

元エンジニアがAIについて、実践を元に発信しているメルマガです！ ぜひご登録ください。

メルマガに登録する

---

出典

• Uthana 料金ページ

• Uthana Text to motion API ドキュメント

• Rokoko Text-to-Motion 紹介

• Rokoko Create

• QuickMagic 公式

• Tencent HY-Motion 1.0（GitHub。VRAM要件はこちらのModel Zoo）

• fal Hunyuan Motion 1B

• fal Hunyuan Motion 0.46B

• Tencent HY-Motion 1.0（Hugging Face）

• HY-Motion 1.0 論文

• 光学式モーションキャプチャスタジオのレンタル料金例

こんにちは、健ちゃんです。

NVIDIAから、机の上に置けるAIスーパーコンピュータが出ていますね。DGX Sparkという名前で、A5サイズ、重さ1.2kg。お弁当箱くらいの本体に、128GBのメモリが積まれています。

値段は、国内でおよそ100万円。

以前からDGX Sparkの名前は耳にしていましたが、スペックのわりに意外とリーズナブル（いや、決して安くはないのですが）だと思い、改めて調べてみる気になりました。

僕はいま、3Dの人体モデル制作とAI動画づくりに取り組んでいます。そこへ「机の上のスパコン」と言われれば、気になりますよね。しかも今はGPUを時間貸しで借りて使っているので、なおさらです。

そこで、購入判断ができるところまで調べてみました。先に結論をお伝えすると、用途によって、分かれます。残念ながら、僕は「待ち」になります。

• 3D制作や動画生成が主目的なら、待ってください。同じ金額でRTX 5090機を組んだほうが速いです。

• 大きなLLMを手元で動かしたいなら、十分に選択肢へ入ります。こちらは5090では代わりが務まりません。

なぜここまで分かれるのか。順を追ってお話しします。

まず、これが何なのかを整理します

DGX Sparkは「小さいゲーミングPC」というより、「128GBのメモリを持つ、小さなAI開発マシン」です。

HDMI 2.1a端子があり、モニター、キーボード、マウスをつないで普通のUbuntuデスクトップのようにも使えます。一方で、同じLAN上のMacやWindowsからSSHやリモートデスクトップで接続し、専用のAI計算機として運用することもできます。

普段使いのPCを置き換えるというより、手元のPCから使う専用マシンとして考えると、役割が分かりやすくなります。

ここで注目していただきたい数字は、二つだけです。メモリ128GBと、メモリ帯域273GB/s。この二つの関係が、この記事の中身のほぼすべてになります。

倉庫と搬出口の話をさせてください

AIマシンの性能は、二つに分けて考えると一気に見通しがよくなります。

一つは、倉庫の広さです。メモリ容量のことで、広いほど大きなモデルを置いておけます。もう一つが、搬出口の広さ。こちらはメモリ帯域で、広いほど1秒あたりたくさん運び出せます。

DGX Sparkは、倉庫がとても広く、搬出口が狭いマシンです。128GBに対して273GB/sという構成になっています。

対するRTX 5090は、まったく逆。倉庫は32GBしかないのに、搬出口は1,792GB/sもあります。実に6.6倍の差です。

つまり、どちらが速いかは一概に決まりません。あなたの荷物が倉庫に入るかどうかで、勝者が入れ替わるのです。

この一点さえ押さえていただければ、あとの数字はすべて説明がつきます。

3D・動画制作では、搬出口の広さが効きます

画像生成や動画生成で使うモデルは、それほど大きくありません。そのかわり、同じモデルを何十回、何百回と往復させます。ノイズを少しずつ取り除きながら絵にしていく仕組みだからです。

荷物は小さいのに、出し入れの回数がとにかく多い。ですから、ここでは搬出口の広さがそのまま制作スピードになります。

実測を見ると、差ははっきり出ています。

だいたい3〜4倍の開きです。ComfyUIでWAN 2.2の5秒動画を作ったところ30分以上かかった、という報告もありました。

なお、TeaCacheやモデルコンパイルといった最適化を入れると2.8〜3倍まで改善した事例はあります。とはいえ、それでも5090には届きません。

そして制作用途には、もう一つ見落とせない話があります。

ARM64という、地味に重い壁があります

DGX SparkのCPUはArm製です。OSはDGX OS 7で、中身はUbuntu 24.04のARM64版になります。

普段WindowsやIntel系のLinuxを使っている方には、ここが効いてきます。制作系のツールには、x86向けのビルドしか配布されていないものが少なくないからです。

実際に報告されている例を挙げてみます。

動かないわけではありません。しかし、「動かすための作業」が継続的に発生します。

制作でいちばん大事なのは、手が止まらないことです。レンダリングの待ち時間より、ビルドエラーを追いかけている時間のほうが、実は制作を殺してしまいます。ここは正直にお伝えしておきたいところです。

ところが、大規模LLMでは景色が変わります

ここからは逆の話になります。

RTX 5090のVRAMは32GBです。70Bクラスのモデルは、そもそも載りません。載らないものは、どれだけ搬出口が広くても運び出せないのです。

DGX Sparkの128GBが効いてくるのは、まさにこの場面でした。

「載らない」と書かれた行こそが、この製品の存在理由です。

小さいモデルなら5090の圧勝でしょう。ところが大きいモデルになると、5090は勝負の土俵にすら上がれません。DGX Sparkのほうは4.6 tok/sという決して速くない数字ながら、とにかく動き続けます。

もう一つ面白いのが、同時実行を増やしたときの挙動です。同時256リクエストでは単発計測の120倍のスループットが出た、という検証がありました。単発レビューの数字だけを見ると、この製品はかなり過小評価されやすいということになります。

エージェントを何本も並列で回す、社内の文書を丸ごと読ませる。こうした使い方では、この特性が素直に効いてきます。

使い方は「机の上のLinuxワークステーション」です

購入前に、運用のイメージも整理しておきます。DGX Sparkはモニターをつないで直接操作できますが、僕なら普段使いのMacやWindowsから接続する専用マシンとして使います。

流れはこうなります。

1. 初回設定を、モニターとキーボードをつなぐか、同じネットワーク上の別のPCから行う 2. 設定後は必要に応じて、同じLANから spark-XXXX.local へSSHで接続する 3. 外出先から使いたい場合は、Tailscaleのようなツールを挟む 4. NVIDIAのAIソフトスタックが最初から入っているので、Docker経由でモデルを動かす

つまり、ローカルでもリモートでも使えます。僕の用途では、普段使いのMacやWindowsから叩く専用の相棒、という位置づけが合いそうです。

ちなみにConnectX-7という200Gbpsのネットワークを積んでいて、2台を直結すると256GB相当のモデルまで扱えます。将来の拡張余地としては、なかなか面白いところですね。

価格の現実も見ておきます

米国では2025年10月に3,999ドルで発売されました。その後、2026年2月にメモリ供給の逼迫を理由として4,699ドルへ値上げされています。

国内価格は、円安と代理店マージンが乗るぶん、さらに高くなります。

在庫も安定しているとは言えません。ASUS Ascent GX10は、一時販売を停止していた時期がありました。

それで、買うべきなのでしょうか

僕の整理は、こうなりました。

待ったほうがいい人

• 画像生成、動画生成、3D制作が主目的の人

• 同じ予算でRTX 5090機を組んだほうが、素直に速く、ハマりどころも少ないためです

今買う価値がある人

• 70B以上のモデルを手元で動かしたい人

• 外に出せないデータでファインチューニングしたい人

• エージェントを並列で長時間回したい人

• データセンターと同じCUDA/NIMスタックで開発し、そのまま本番へ持っていきたい人

僕自身は、いまのところ「待ち」です。3Dと動画が主戦場ですから、この買い物では速くなりません。GPUを時間貸しで借りる運用のほうが、当面は理にかなっていると判断しました。

ただし、この評価は固定ではありません。発売直後よりソフトウェアはかなり成熟していて、2026年に入ってからのアップデートで累計2.5倍の性能向上が報告されています。ARM64向けのビルドも、少しずつ揃ってきました。

「いま買うと損をする」のではなく、「いまの僕の用途には合わない」。この違いは、けっこう大きいと思っています。

手元に大きなモデルを常駐させたくなった日が、僕にとっての検討タイミングです！

編集後記

こうして数字を並べてみると、AIの世界では「速さ」と「大きさ」がまったく別の資源なのだと、あらためて感じます。

そして今の僕に足りないのは、たぶんどちらでもありません。3Dの人体モデルを納得のいく形に仕上げる、その手数のほうです。マシンを速くしても、作り方が定まっていなければ意味がないんですよね。

道具の検討は楽しいものですが、それ自体が目的にならないよう気をつけながら、今日も手を動かしていきます！

メルマガ

元エンジニアがAIについて、実践を元に発信しているメルマガです！ ぜひご登録ください。

メルマガに登録する

---

出典

• NVIDIA DGX Spark 公式

• NVIDIA DGX Spark 初回設定ガイド

• DGX Spark (GB10) vs 5090 実測比較

• Tom's Hardware レビュー

• 同時実行スループット検証

• ComfyUI on NVIDIA DGX Spark

• Hunyuan3D 2.1 in Docker on DGX Spark

• Blender ARM64 ビルド

• 国内価格比較

こんにちは。健ちゃんです。

Cloudflareが「Cloudflare OS」というものを公開しました。社内で数千人の従業員が使っているAIの作業場を、そのままオープンソースにしたものです。

ニュースとしては「へえ」で終わる話かもしれません。ですが中身を読んでいくうちに、これは他人事ではないなと思いました。そこで実際に、自分のドメインに Cloudflare OS を建ててみました。

Cloudflareへ払うのは月5ドルです。作業は半日でした。

この記事では、何ができたのか、どこで詰まったのか、そして建ててみて初めて分かったことを書きます。建ててみたい方には手順の勘所を、そうでない方にも持ち帰れるものを用意しました。

---

そもそも、これは何なのか

先に、Cloudflare OS が何者なのかをはっきりさせておきます。

一言でいうと、自分の会社の事情を知っていて、自分の会社のシステムを安全に触れるAIの（クラウド上の）作業場です。

ChatGPT や Claude との違いは2つあります。

1つ目は、会社の文脈を最初から持っていることです。社内用語や業務手順を「スキル」として登録しておくと、AIがそれを前提に動きます。毎回説明し直す必要がありません。

2つ目は、社内システムに手が届くことです。GitHub、Notion、Slack、Googleドライブ。こうしたサービスに繋いで、AIが直接読み書きできます。

ここで当然、こう思われるはずです。「AIに社内システムを触らせるなんて怖い」と。

その怖さにどう答えるかが、この製品の全部です。以下の図が、その答えの形です。

利用者とAIの間に、そして AI と社内システムの間に、それぞれ関所が置かれています。手前が Cloudflare Access（誰が入れるか）、奥が Gatekeeper（AIが何を触れるか）です。AIは社内システムに直接繋がりません。必ず門番を経由します。

特徴はもう1つあります。この作業場では、一人ひとりが自分専用のアプリを作れます。 「経費精算の一覧を出すツール」のようなものを、AIに作らせてその場で使えます。そのアプリは利用者ごとに完全に隔離された状態で動きます。

なぜそんな面倒な作りにするのか。その理由は、10年前に遡ります。

---

10年早すぎた人が、戻ってきた

先に背景を1つだけ。ここを知っていると、Cloudflare OS という製品が全く違って見えます。

Cloudflare OSを設計したのは Kenton Varda という技術者です。いまCloudflare OSが動いている基盤、Cloudflare Workers そのものを作った人でもあります。

その人が2015年に、Sandstorm.io というスタートアップをやっていました。掲げていた思想は「アプリを、利用者ごと・文書ごとに完全に隔離した状態で動かす」というものでした。

その会社は成功しませんでした。理由は単純で、当時の技術では隔離のコストが高すぎたからです。一人ひとりに専用の実行環境を配るなど、贅沢すぎて割に合いませんでした。

そして10年が経ち。

Cloudflare Workers が使っているV8アイソレートという仕組みによって、隔離のコストはおよそ100分の1になりました。ブラウザがタブごとにJavaScriptを隔離しているのと同じ技術を、サーバー側で使うやり方です。専用のサーバーを一人ずつ立てるのに比べれば、桁が違います。

安くなっただけではありません。当時は存在しなかったものが現れました。AIエージェントです。

そしてAIエージェントには、人間の従業員にはない性質があります。指示を取り違えます。読んではいけないものを読みます。「直しました」と報告しながら直っていないことがあります。 悪意があるわけではありません。ただ、確実ではないのです。

Cloudflare はこれを欠陥として扱いませんでした。前提として扱うことにしたんです。エージェントは信用できない。ならば、間違えても被害が出ない作りにすればいい、と。

ここが Cloudflare OS の設計の出発点です。この「信用しない」がどう形になっているかは、記事の後半でGatekeeperの仕組みとして詳しく見ていきます。

さて、AIが信用できない働き手だとすると、隔離は贅沢品ではなく必需品になります。10年前に早すぎたアイデアが、前提条件の変化によって復活したわけです。Cloudflare OSは、その再挑戦として作られています。

---

Gatekeeper — 鍵ではなく、リードを渡す

ここがCloudflare OSの心臓部です。全体を貫く原則は、公式ブログのこの一文に表れています。

> agents start with access to nothing

エージェントは、権限ゼロから始まる。何も触れない状態が初期値で、許したものだけが触れるようになります。

僕たちが普段やっていることを思い出してください。AIに GitHub を触らせたいとき、どうするか。アクセストークンを発行して、そのまま渡します。

このとき何が起きているか。トークンは、それを持つ人の権限そのものです。渡した瞬間から、AIはあなたと同じことが全部できます。issue を読むだけのつもりでも、リポジトリを消す権限まで一緒に渡っています。

Gatekeeper は、これをやりません。

Gatekeeper は、サービスごとに立てる小さな中継役です。トークンはGatekeeperが握ったまま、AIには渡しません。AIが受け取るのは「この操作だけができる」という権限の束です。

具体的にはこうなります。

| 項目 | 従来のやり方 | Gatekeeper | |---|---|---| | AIが持つもの | アクセストークン本体 | 「issue一覧を読む」という能力 | | できることの範囲 | トークンの権限すべて | 許可した操作だけ | | 対象の絞り込み | 基本できない | このリポジトリだけ、と指定できる | | 危険な操作 | そのまま実行される | 人間の承認を挟める | | 何を読んだか | 分からない | 全部記録される |

たとえばGitHubなら、「ENGチームのオープンなissueを読む」ことだけを許して、プルリクエストのマージには人間の承認を必須にする、といった設定ができます。AIはトークンの文字列を一度も見ません。

鍵は、持ち主の権限そのものです。能力は、繋いだリードです。 犬にリードを付けて散歩するのと、家の鍵束ごと渡して「散歩してきて」と言うのとの違いです。

さらに、読んだものが記録されて回る

Gatekeeper にはもう1つ、Observation Log という仕組みがあります。

エージェントが読んだリソースを全部記録して、その記録が成果物にくっついて回ります。 誰かがその成果物を開こうとしたとき、門番が「この人は元データを見る権限を持っているか」を確認してから表示します。

これは、いま多くの組織が気づきはじめている問題への回答です。AIは複数のシステムを横断してデータを結合できます。すると、それぞれ別々に権限管理していたはずの情報が、AIの出力という形で一箇所に集まります。そしてその出力が、元データを見る権限のない人へ渡ってしまいます。AIが権限の抜け道になるわけです。

Observation Log は、成果物のほうに出自を持たせることで、この抜け道を塞ぎます。

情報を成果物につける。 なかなか面白い発想ですね。

---

建ててみます

ここからは実際の作業です。

僕はすでにCloudflareでドメインを1つ運用していたので、そこのサブドメインに建てることにしました。この記事で書くのは、そちらの手順です。使うリポジトリはこちらです。

https://github.com/cloudflare/cloudflare-os-starter

ドメインを持っていない場合は、ワンクリックで workers.dev のアドレスに建てる道もあります。

https://os.cloudflare.app/deploy

ただしこちらは僕が試していないので、動きを保証できません。 サインインの設定がどうなるかを、建てた直後に必ず自分の目で確認してください。理由は「建てる前に確認してほしいこと」の節に書きます。

必要だったもの

| 項目 | 内容 | |---|---| | Workers Paid | 月5ドル。これは必須でした | | Zero Trust | 無料プランで足ります | | R2 | 有効化が必要。すでに使っていれば不要 | | ドメイン | Cloudflareで運用中のもの1つ | | Node.js 24 と pnpm 11 | 手元の環境 |

Workers Paidが必須なのは、Dynamic Worker Loader という機能を使うためです。AIが作ったアプリを、その場で読み込んで隔離した状態で動かす部分にあたります。この製品の土台にあたるので、ここを外すことはできません。無料プランのままデプロイしようとすると失敗します。

手順の骨格

1. Workers Paid にアップグレードする 2. Zero Trust を有効にする 3. Access のアプリケーションを作る 4. リポジトリを取得して依存関係を入れる 5. deployment.jsonc に値を埋める 6. pnpm check で検証して pnpm deploy

デプロイが通ると、Worker が4本、KVが3本、R2バケットが1つ、そしてDNSレコードとTLS証明書が自動で作られます。僕の場合、デプロイ自体は3分ほどで終わりました。

---

詰まったところ

ここが本題です。全部で18か所つまずきました。ただ、全部を並べても読むほうが疲れるだけです。あとから建てる方がつまずきやすく、知っておくと時間が浮く5つに絞って書きます。

なお、Cloudflare側の設定を実際の画面で追う手順書は、別記事にまとめました。 建てながら横に置いて使ってください。

https://note.com/kenhfp/n/n94cfd0ba8242

無料なのに、カードの同意を求められる

Zero Trust の無料プランを選ぶと、決済画面に飛ばされます。本日支払額は0ドルと表示されているのに、次の2つにチェックを入れろと言われます。

• 利用規約とプライバシーポリシーに同意します

• このカードに対し、無料枠を超える使用量を毎月課金することを許可します

「無料と書いてあったのにカードの話が出てきた」と手が止まる方は多いと思います。ここは仕様です。無料枠は50ユーザーまでなので、一人で使う分には超えません。

チーム名は世界中で早い者勝ち

Zero Trust を有効にすると、チーム名が自動生成されます。僕の場合は summer-scene-fcd1 という文字列でした。

これは変更できます。ただし 〇〇.cloudflareaccess.com というアドレスになるため、同じ名前はCloudflare全体で1つしか使えません。 短い一般的な名前はまず取れないと思ってください。僕も希望した名前は既に使われていて、別の名前にしました。

さらに、変更するなら一番最初にやってください。後から変えるとログイン画面の表示が古いままになったり、連携済みの設定をやり直すことになります。

AUDタグという、奥に隠れている値

設定ファイルに書き込む値の1つに「AUDタグ」があります。これは Access のアプリケーション1つ1つに割り当てられる64文字の識別子です。

役割はこうです。Access は認証を通った人に署名付きのトークンを渡します。そのトークンには「これはどのアプリ向けか」が書き込まれていて、Cloudflare OS 側はそれが自分宛てかどうかを検証します。これがないと、同じ組織の別のサイト用に発行されたトークンを、そのまま使われてしまいます。

問題は、この値が見つけにくいことです。アプリの一覧にも、詳細タブにも出てきません。「追加設定」タブに移動して、そこを下にたどってようやく現れます。 初見で必ず迷う場所でした。

ネット上の手順書が、もう古い

Zero Trust のダッシュボードは最近URLの構造が変わっています。検索で出てくる手順書の多くが古いパスを指していて、そのまま開くと404になります。

対処は単純で、URLを直接打たず、左メニューをたどってください。 「Access コントロール」から「アプリケーション」へ進みます。

検証コマンドが親切だった

これは褒めるところです。設定ファイルの穴埋めを1つ忘れたまま pnpm check を実行したところ、こう返ってきました。

Deploy failed. deployment.jsonc: Replace deployment placeholder <ACCESS_AUDIENCE>.

デプロイしてから失敗するのではなく、手前で止めてくれます。地味ですが、この手のツールでは大事なところです。

---

建ててから分かったこと

ここからが、実際に動かさないと書けない部分です。

デプロイしただけでは、AIは喋りません

設定ファイルにも管理画面にも、AIの設定項目はありません。サインインしたあと、アプリの中で設定します。 左下のアイコンから「Providers」を開き、モデルを選んでAPIキーを登録します。

そしてこのキーは、Cloudflareのものではありません。自分のOpenAIやAnthropicのアカウントのものです。つまり、推論の費用は自分持ちです。

選べる先はこうなっていました。

| プロバイダー | 例 | |---|---| | Cloudflare Workers AI | Kimi K2.7 Code、GLM 5.2 | | Anthropic | Claude Opus 5、Sonnet 5、Haiku 4.5 | | OpenAI | GPT 5.6 Sol、Luna、Terra | | Google | Gemini 3.6 Flash | | Ollama | ローカルで動かしているモデル |

最後のOllamaがあるのは見逃せません。手元で動かしているモデルを繋げば、API課金なしで回せます。

1往復で、4円

キーを入れて、試しに一言だけ聞いてみました。「あなたはどのモデルですか。1行で答えてください」と。

返ってきたのは1行です。そして画面の下にこう表示されました。

5,116 tokens    $0.0261

1行の返事に、5,116トークン。日本円でおよそ4円です。

会話の中身が短くても、システムプロンプトと会社の文脈が毎回積まれるため、この単価になります。画面の右上には、そのワークスペースの累計金額が表示され続けます。

この数字を見た瞬間に、公式ブログの記述が別の意味を持ちはじめました。

Cloudflareは、すべての推論をAI Gatewayという中継点に通す設計にしています。そして人ごと・チームごと・ワークスペースごとに費用を追跡できるようにしています。ブログにはこう書かれています。高価なモデルは、最も難しい仕事にだけ使われるようにする、と。

読んだときは、大企業向けの管理機能という程度に思っていました。ですが自分の画面で4円を見ると、話が変わります。これは全社員に配る製品です。一人が一日に何十往復もして、それが何千人分になったらどうなるか。コストの追跡は、あれば便利な機能ではなく、この製品が成立するための前提だったわけです。

---

工房に、仕事をさせてみます

建てただけでは、ただの空き家です。せっかくなので働かせました。

頼んだのは記事のネタ帳です。日本語で3文だけ書きました。

> 記事のネタ帳アプリを作ってください。記録する項目は、タイトル、狙い、状態（未着手・執筆中・公開済み）、公開先アドレスの四つです。一覧表示と、新しいネタの追加ができるようにしてください。状態で絞り込めると助かります。画面の文言は日本語でお願いします。

1分ほどで、server.js と client.js と README.md の3つが出てきました。消費は9,721トークン、$0.2150です。

ここで面白いのが、すぐには反映されないことでした。画面に「Pending changes」と出て、「Accept changes」を押すまで待たされます。AIが書いたコードが、人間の承認を挟んでから初めて動く。Gatekeeperの節で見た「危険な操作には人間を挟む」という思想が、コードの反映にもそのまま効いているわけです。

承認すると、その場でアプリが立ち上がりました。入力フォーム、一覧、状態での絞り込み。頼んだとおりの画面です。

ChatGPTにコードを書かせるのと、何が違うのか

ChatGPTに「こういうアプリを作って」と頼んでも、コードは出てきます。ですがそこから先が自分の仕事です。ファイルに保存して、実行環境を用意して、保存先を繋いで、どこかへデプロイする。

Cloudflare OSでは、その全部が済んだ状態で出てきます。アプリはもう動いていて、アドレスがあって、データも保存されます。 保存先はこのアプリ専用に割り当てられたDurable Objectで、他のアプリからも、他の利用者からも見えません。

出てくるのはコードではなく、動いているアプリです。ここが決定的に違うところでした。

そして、バグを踏みました

ネタを入力して「ネタを追加する」を押しました。

何も起きません。

一覧は0件のまま。リロードしても保存されていません。キーボードで押しても同じでした。エラーメッセージすら出ません。うんともすんとも言わないという、一番たちの悪い壊れ方です。

症状だけを日本語で投げると、エージェントは自分の書いたコードを読み直し、原因を挙げてきました。ただし最初の答えは外れです。承認して試しても、まだ動きません。もう一度突き返して、ようやく真因に届きました。

> 原因は、ボタン押下が form の submit イベントに依存していたことです。Gadget の iframe 環境では通常のフォーム送信が期待通りに発火しない／ブロックされるケースがあり、その場合はアプリ側の追加処理まで到達しません。

このアプリはサンドボックスの中で動いています。そのサンドボックスはフォーム送信を許可していないので、送信そのものが黙って落ちていたわけです。ボタンを普通のボタンに変え、クリックから直接処理を呼ぶように書き換えて、動くようになりました。

3件登録して、状態のバッジも絞り込みも効いています。note.com/kenchan/cloudflare-os と略して入れたアドレスが、https:// 付きに直してリンクになっているのも、直したついでの仕事です。

ここから持ち帰ったこと

作った当人が、動作確認をしていませんでした。そして一度目は「直しました」と報告しながら、直っていませんでした。

記事の前半でこう書きました。エージェントは指示を取り違える、読んではいけないものを読む、「直しました」と報告しながら直っていないことがある、と。その3つ目を、自分の画面で踏んだわけです。

これは製品の欠陥というより、AIエージェントというものの性質でしょう。だからこそ Cloudflare OS は、コードの反映に人間の承認を挟みます。承認なしで即反映される作りだったら、壊れたアプリが壊れたまま増えていくだけです。

信用しないけれど、使う。 その距離の取り方が、製品の作りそのものに現れていました。作らせて、壊れて、直させて、動くまで。かかったのは合計でおよそ130円です。

安い授業料だったと思っています。

---

建てる前に確認してほしいこと

ここは飛ばさないでください。お金の話です。

Cloudflare OS は、建てた人のCloudflareアカウントの上で動きます。ということは、そこで動いたWorkerの実行時間も、保存したデータの容量も、全部あなたへの請求になります。

誰がここに入れるのかを、必ず自分で確認してください。

守りは二重になっています。

1つ目は、Cloudflare Access です。 誰がサインインできるかを、メールアドレス単位で指定します。僕は自分1人だけを許可しました。それ以外の人はアプリの手前で止まります。

2つ目は、`/admin` の Access タブにある「Allow new sign-ups」です。 これがオンだと、新しいアカウントが作られます。説明文にはこう書かれています。

> When off, existing users can still log in but no new accounts can be created.

僕の環境では、初期状態でオンになっていました。 Accessで1人しか通れないので実害はありませんが、Accessのポリシーを広く取るなら、真っ先に切るべき設定です。

AIの利用料については、少し事情が違います。デプロイ時に aiGateway.enabled: false としている場合、デプロイ側が費用を持つモデルは1つも配られません。 公式ドキュメントにこう書かれています。

> Deploys without an AI secret; no funded model catalog is advertised

APIキーはサインインした人が各自で登録する作りなので、他人が入ってきても、その人が自分のキーを持ち込まないとAIは動きません。AI費用の垂れ流しは起きにくい構造です。

ただし繰り返しますが、Cloudflare側の利用料は所有者持ちです。 入口を絞る。これだけは最初にやってください。

なお、ワンクリックでデプロイする方式については、何で認証をかけるのかを僕は確認していません。使う場合は、建てた直後にサインイン設定を必ず自分の目で確認してください。

---

建てない人が持ち帰れること

ここまで読んで「自分は建てないな」と思われた方へ。むしろ、こちらが本題かもしれません。

Gatekeeperの考え方は、そのまま自分の環境に持ち込めます。

いま、お手元の `.env` に何が入っているでしょうか。 MCPサーバーに、必要以上の権限を持つトークンを丸ごと渡していないでしょうか。AIに「このリポジトリを見て」と頼んだとき、そのAIは他のリポジトリも消せる権限を持っていないでしょうか。

Cloudflare OS を建てなくても、明日からできることが3つあります。

用途ごとにトークンを分けて発行すること。 1本のトークンを使い回さない。

読み取り専用と書き込みを別のキーにすること。 調べものをさせるだけなら、書き込み権限は要りません。

AIが何を読んだかのログを残すこと。 何かあったときに追えるようにしておく。

どれも地味です。ですが、Cloudflare が数千人規模で運用するために作った仕組みを、一人分に縮めると、だいたいこの3つになります。

---

誰が建てるべきか

正直なところを書きます。

建てる価値があるのは、次のような方です。 自分のドメインを持っていて、複数のサービスをAIから触らせたくて、権限管理を自分で設計したい方。あるいは、この設計思想を手を動かして理解したい方。

やめておいたほうがいいのは、次のような方です。 単にAIと会話したいだけの方。それなら既存のサービスを使うほうが速くて安いです。それから、ターミナル作業に抵抗がある方。前半と後半はブラウザ操作ですが、真ん中はコマンドを打ちます。

なお現時点では、公式ドキュメントが整備途中で、マネージド版もまだ提供されていません。早期アクセスの製品だと思って触るのが正しい距離感です。

限界もはっきりしています。「AIは重大なセキュリティバグを作れない」という主張が成り立つのは、アプリが箱の外に影響しない間だけです。役に立つアプリは、いずれ必ず外に触ります。人間が承認のループに入り続ける構造は、自律性とのトレードオフでもあります。

それでも、エージェントを信用しないという前提から出発して製品を作ったという事実は、記録しておく価値があると思っています。いまの業界は、AIに権限を渡す方向へどんどん進んでいます。その逆を行く設計が、どこまで実用に耐えるのか。手元で動かしながら見ていけるのは、贅沢な状況です。

---

まとめ

月5ドルで、自分のドメインにAIの工房が建ちました。

半日かかりましたが、詰まりどころを全部避けられれば1時間ほどで終わる作業だと思います。この記事に書いた落とし穴が、その助けになれば幸いです。

そして何より、建ててみて良かったのは、読んだだけでは分からなかったことが分かったという点です。1往復4円という数字を自分の画面で見なければ、コスト追跡機能の意味を理解することはなかったはずです。AIが作ったアプリが動かず、一度目の修正でも直らない。あの手触りも、記事を読んでいるだけでは絶対に得られません。

「エージェントは信用できない」という設計思想を、ここまで実感つきで納得できるとは思っていませんでした。

新しいものが出たとき、記事を読んで分かった気になるのは簡単です。ですが5ドル払って半日使うと、その先が見えます。今回はそれが確認できただけでも収穫でした。

みなさんもぜひ、自分の工房を建ててみてください！

こんにちは、健ちゃんです。

企業向けの高い道具が個人へ降りてくるとき、最初に消えるのは値段だと思っていました。でも、実際に触ってみて、順番が逆だと分かりました。

先に消えたのは「分からない」のほうでした。

イケハヤさんが開発しているマーケティングOS「Rondo」のテスターを始めました。まだ開発中のツールですが、インストールしてみて、これはかなり大きな変化になりそうだと感じています。

今日は、その話を書きます。Rondoはまだ発売前なので、最後に「発売を待たずに今日できること」も一つだけ書いておきますね。

導入作業のほとんどを、AIが進めてくれました

テスターのお話をいただき、僕はすぐに「やります」と返事をしました。最初はダウンロードで少しつまずきましたが、その後、夜からインストールを開始しました。

驚いたのは、導入作業がかなり自動化されていたことです。インストール方法が書かれたMarkdownファイルに従って、必要な作業をどんどん進めてくれます。

もちろん、途中で確認される項目もあります。たとえば、メルマガ配信に使う外部サービスの設定や、利用するドメインについてです。Rondo自体はCloudflare上に展開され、そこへアクセスして利用する形になります。そのため、Cloudflareを使っていない人は、まずその設定から始めることになります。

僕の場合は、メルマガの送信元ドメインに関係する細かな設定まで判断し、進めてくれました。

技術的な内容をすべて理解していなくても、必要な質問に答えながら進められる。この安心感は、かなり大きいです。

「高いから使えなかった」だけでは、なかったんです

Rondoはいわゆるマーケティングオートメーション、つまりMAのツールです。

これまでのMAが個人に手を出しにくかった理由は、二つあります。

一つ目は料金です。企業向けのサービスでは月額数万円からというものもあり、配信数が増えるほど料金も上がります。個人が試しに使ってみるには、負担が大きすぎますよね。

二つ目は難しさです。メルマガ配信だけではなく、リスト管理や分析まで含めて全体を設計する必要があります。機能が多いぶん設定項目も多く、どこを触ればいいのか分かりにくい。

僕は今もメルマガ配信にマイスピーを使っています。マイスピーでも自動化はできますが、以前から使い方が難しいと感じることがありました。そこにSNSや分析まで加わると、企業のマーケティング担当者でも運用はかなり大変だったと思います。

ここで考えてみてください。もし月額数百円のMAがあったとして、あなたは使いこなせたでしょうか。

僕は、たぶん契約したまま放置していたと思います。だから、値段だけが壁だったわけではないんです。

覚えてから使う道具から、聞きながら使う道具へ

Rondoの面白さは、AIネイティブに作られていることです。

分からないことがあればAIに聞く。忙しいときは、できる作業をAIに任せて進めてもらう。これまで複雑だったMAの操作を、AIとのやり取りに変えていけます。

つまり、覚えてから使う道具ではなく、聞きながら使う道具になったということです。

この差は、値段の差より大きいと感じています。学習に必要だった時間が、そのまま運用の時間へ回せるからです。

僕は、Rondoのようなツールがこれから増えていくのではないかと考えています。従来なら専門知識を持つ人が時間をかけて設定していた仕組みを、AIと一緒に作り、運用する。Rondoは、その流れのかなり早い段階にあるプロダクトの一つではないでしょうか。

しかも、開発者自身が日々使い、実績を出している仕組みが土台です。自分で一から似たものを作ると、動くところまでは到達できても、「この設計で本当に大丈夫か」と不安になることがあります。すでに実運用されている仕組みを、手の届きやすい価格で使えるなら、時間を買う投資としても魅力的です。

配信コストも、小さく始められます

メルマガ配信には、Resendという外部サービスを使います。配信数が少ない段階なら、無料枠の範囲で始められる可能性があります。読者が増えた場合も、必要な配信量に応じてプランを選ぶ形になります。

僕のメルマガ読者は、昔から登録してくださっている方を含めて3000人弱います。ただ、今も実際に読んでくださっている方だけを考えると、移行を機にリストを整理したほうがいいかもしれません。

新しい配信スタンドへの登録をお願いし、今も読みたい方に移っていただく。そうすれば、読者数は減っても、よりアクティブな人たちに届けられるようになります。

人数だけが多いリストではなく、本当に読んでくれる人との関係を作る。その意味でも、移行はよいきっかけになりそうです。

商品がなくても、リストづくりは始められます

「自分には販売する商品がないから、まだMAは必要ない」

そう思う方もいるかもしれません。でも僕は、商品がなくても使う価値はあると考えています。

自分の商品がなくても、誰かの商品を紹介することはできます。そのとき、SNSで一度投稿するだけでは、なかなか購入にはつながりません。フォロワーが多かったとしても、投稿が流れてしまえば終わりです。

一方、メルマガなら、読者が内容をきちんと読み、自分に必要かどうかを判断できます。だからこそ、まずは自分の発信に興味を持ってくれた人のリストを作ることが大切です。

そのリストを集める導線を作り、反応を分析していく。商品ができてから慌てて始めるのではなく、今から少しずつ土台を作っておくのです。

これは将来の売上だけではなく、あなたの発信を本当に待ってくれる人とつながるための準備でもあります。

今日できることは、一つだけです

Rondoはまだ開発中で、僕もテスターとして触っている段階です。ですから、この記事を読んで今日すぐRondoを使う、という話にはなりません。

その代わり、今日できることが一つあります。

自分の発信に興味を持ってくれた人を、受け取れる場所を作っておくことです。専用のページでなくてもかまいません。記事の末尾でも、プロフィール欄でも、置ける場所ならどこでもいいと思います。

道具が降りてくるのを待ってから土台を作ると、そこからまた時間がかかります。逆に、受け取る場所さえ先にあれば、道具が整った日から動き出せます。

高くて難しかったものが、AIによって少しずつ個人の手に降りてきています。降りてきたときに、すぐ使える側にいましょう！

編集後記

僕は今、3Dの人体モデル制作にも取り組んでいます。

これが本当に難しくて、驚くほど細かなところでうまくいかないことがあります。それでも、3Dは面白いんですよね。しっかりした人体モデルを作る流れを確立し、いつかそれを使って面白いものを作りたいと思っています。

Rondoのテストも3D制作も、まずは触って、失敗して、少しずつ理解していくしかありません。新しいものに挑戦できる環境を楽しみながら、今日も前に進めていきます！

お知らせ

2Dキャラモーションのスキルが

無料でゲットできます！

こちらからぜひ、ご登録ください！

Brainも8月14日販売開始します！

登録者のみ、割引クーポンをお送りしますね。

↓

一忍（いちにん）といいます。もともとは「AIに任せてゲームを1本作り切る」講座で、そこに誰でも発信者として乗れるようにしました。

そもそもMCPとは

MCP（Model Context Protocol）は、AIエージェントに外部の道具やデータをつなぐための、差し込み口の規格です。

これまでは、AIに何かを読ませたいたびに、コピーして貼り付けていました。MCPでつなぐと、AIが自分で取りに行けるようになります。USBのように、規格が同じなら何にでも挿せる、と考えてください。

一忍は、その差し込み口のひとつとして立っています。

つなぐ

Claude Code なら、これ1行です。

claude mcp add --transport http --scope user ichinin https://ichinin.kenty.app/mcp

実行するとブラウザが開きます。許可を押せば繋がります。APIキーもトークンも発行しません。 鍵を手で作ってコピーして貼る、という手順が要らなくなりました。

受け取る

繋いだあとは、あなたが探しに行くのではなく、あなたのAIが受け取ります。

発信者の一覧から選んで購読すると、新着がAIの手元に流れてきます。記事はそのまま読めます。配られたスキルやテンプレ（zipで届きます）は、AIがそのまま取り込みます。

発信する

申請して承認されると、投稿と配布の機能が開きます。書いた記事も、作ったスキルも、購読者のAIエージェントへ直接届きます。

いま発信者を募集しています。 申請はサイトのポータルからできます。本人確認のため、X・Substack・Instagram・YouTube のうち最低1つのURLをいただいています。

なぜ監査するのか

ここが、作っていていちばん時間をかけたところです。

AIエージェントが受け取るzipは、人が中身を見ないまま展開されます。 「便利なスキルです」と言われて渡されたものを、AIはそのまま開いて実行しようとします。ここが素通しだと、配信の仕組みそのものが攻撃の配達経路になります。

なので、配る前にAIに中身を読ませて検査します。通ったら、その時点のハッシュを覚えます。 ハッシュは中身の指紋のようなもので、1バイトでも変われば別の値になります。

そして配るたびに、保管してある実体をもう一度読んでハッシュを取り直し、覚えている値と突き合わせます。合わなければ配りません。差し替えを見張る仕組みを別に作らなくても、中身が変われば自動的に未検査へ戻ります。

記事のほうは検査を通しません。読み物だからです。代わりに公開の瞬間に、他人のAIを乗っ取ろうとする文面だけを止めています。

講座も同じ接続で

一忍はもともと講座です。ゲームを1本作り切るまでの57本の記事を、AIが教科書として読み進め、あなたは手を動かします。

会員でなくても、末尾に ?guest=1 を付ければ教材だけは読めます。

名前は「一人前」のもじりです。術を覚えて、一忍前。

https://ichinin.kenty.app/mcp-setup

こんにちは、健ちゃんです。

先に結論から書きます。

配ったものは、受け取った人の手元で行方不明になります。置き場所を作るだけでは足りません。AIが取りに来られる口を付けると、人が探す工程そのものが消えます。

その口がMCPです。読む側は1行つなぐだけで、登録も課金も要りません。今日はその話を書きます。

配る側も、同じように分からなくなります

メルマガの読者へスキルやツールを配る機会が、少しずつ増えてきました。

最初のうちは、メールに直接添えて渡していました。数が一つか二つなら、それで困りません。

ところが、配るものが増えると状況が変わります。受け取る側は、以前もらったものを探し、それが最新版かどうかを確かめ、新しく配られたものを見落とします。

そして困ったことに、配る側の僕も同じでした。どれを誰に案内したのか、どれを更新したのか、だんだん分からなくなってきたんです。

だから、置き場所を一つ作ることにしました。それが「一忍（いちにん）」という会員サイトです。

置き場所を作っただけでは、半分でした

一忍には、AIに任せてゲームを一本作り切るまでの手順を、57本の記事として置いています。企画の立て方、プロトタイプの作り方、キャラクターの動かし方、AIへの任せ方まで、一話ずつ「術」という単位で並べています。

記事は、登録しなくても全部読めます。メールアドレスを登録していただくと、講座で作った成果物（スキルやコード）も受け取れます。

ここまでは、よくある会員サイトです。

でも、作りながら気づいたことがありました。置き場所を用意しても、結局は人がブラウザを開いて、探して、ダウンロードして、AIに読ませることになります。手間の総量は、あまり減っていません。

そこで、もう一つの入口を付けました。AIが直接読みに来られる口です。

AIが取りに来る口を付けました

一忍は、Webサイトであると同時に、MCPサーバーになっています。

MCPは、AIエージェントが外部の情報やツールへつながるための仕組みです。難しく聞こえますが、使う側がやることは接続だけです。

Claude Codeをお使いなら、この1行で繋がります。

claude mcp add --transport http --scope user ichinin https://ichinin.kenty.app/mcp?guest=1

必要なのはこれだけです。会員登録も、APIキーの取得も要りません。末尾の guest=1 が、登録なしで読める範囲だけを開ける印になっています。

繋いだあとは、AIにこう頼んでみてください。

「一忍の術を一覧して、最初の1本を読んで要約して」

ブラウザを開かず、記事を探さず、コピーもせずに、AIが読んで返してきます。所要時間は、1行を貼り付けて数十秒です。

うまくいかなければ、外すのも1行です（claude mcp remove ichinin）。何かが壊れることはありませんし、お金もかかりません。まず繋いでみて、合わなければ外す。それでいいと思っています。

人が読むメルマガと、AIが購読するMCP

会員登録をして繋ぐと、読める範囲が広がります。講座の成果物を受け取ったり、進捗を記録したり、購読している発信者の新着を受け取ったりできます。

つまり、これまでのメルマガと同じことを、AI向けにやっているわけです。

これまでのメルマガは、人が登録して、人が受け取り、人が読むものでした。これからは、AIが新着を受け取って、要約して、その日の報告に混ぜて渡してくれる形が増えていくと思っています。

僕自身、あるアプリのMCPから新着記事を取ってきて、AI社員に要約させて報告してもらっています。アプリを起動しなくても、いつもの作業の流れの中に情報が入ってきます。

これは、情報の届き方が変わるということです。人に届けるだけでなく、その人のAIに届ける。発信の宛先が一つ増えた、と言ってもいいかもしれません。

受け取るだけでなく、発信する側にも開けました

もう一つ、一忍には発信する側の口も付けました。

承認を受けた発信者は、自分の記事やお知らせをMCP経由で流せます。読者はその発信者を購読して、自分のAIで受け取ります。

一つのMCPに繋いでおけば、読みたい発信者を選んで登録できる。役割としては、いまのメルマガ配信スタンドに近いものを、AI向けに置いた形です。

もちろん、MCPは繋げば繋ぐほど良いわけではありません。接続先を増やしすぎると、AIが必要なものを見落としたり、動作が重くなったりする可能性があります。だからこそ、まとめて扱える形に意味があると考えています。

正直に言うと、この部分はまだ動かし始めたばかりです。デバッグも十分ではありません。それでも、早い段階で触ってみるほうが、完成を待つより見えるものが多いと思っています。

まずは1行だけ、繋いでみてください

新しい仕組みは、説明を読んでいる間は他人事のままです。手元で一度動くと、そこから急に自分の話になります。

今日お願いしたいのは、それだけです。上の1行をAIに貼り付けて、「一忍の術を一覧して」と頼んでみてください。

うまく動いたら、その先はご自身の発信にも同じことができます。あなたが誰かに何かを配っているなら、その届け先に、相手のAIを加えられるということです。

人が読むメルマガと、AIが購読するMCP。この二つが揃うと、発信の形はきっと変わっていきます。まずは一行、試してみましょう！

編集後記

会員サイトを作っている途中で、「MCPの配信スタンドも作れそうだな」というアイデアが浮かびました。一つ作ると、そこから次の仕組みが見えてくるのが開発の面白いところですね。

いまはキャラクターモーションのスキルとアプリの準備も進めています。事前登録してくださった方は27名。本当にありがたいです。

まずは今回の会員サイトとMCPを実際に触ってもらいながら、使いやすい形へ育てていきます！

一忍について

AIに任せてゲームを一本作り切るまでの手順を、工程順に57本置いています。記事は登録なしで全部読めます。メールアドレスを登録していただくと、講座で作った成果物（スキルやコード）も受け取れます。 ↓

https://ichinin.kenty.app/join

MCPの繋ぎ方は、こちらにまとめています。 ↓

https://ichinin.kenty.app/mcp-setup

こんにちは、健ちゃんです。

先に結論から書きます。

キャラクターの魅力を伝えるのに、大きく動かす必要はありませんでした。まばたきひとつ、髪のわずかな揺れだけで、置かれた絵はそこにいるキャラクターへ変わります。

いま、忍術ラボという2048型のパズルゲームを作っています。同じ数字のパネルを合体させて、より大きな数字を作っていくゲームです。

基本の部分だけなら、その日のうちに形になります。ところが遊んでみて、こう思いました。

「ゲームとして動くだけでは、なんだか全然おもしろくないな」と。

そこで加えることにしたのが、キャラクターの魅力です。今日はその過程で分かったことを書きます。

可愛い絵を置いても、背景に見えました

最初にやったのは、ゲーム画面にキャラクターの静止画を置くことでした。

絵そのものは可愛いんです。単体で見れば、しっかり魅力があります。

ところが、ゲームの中に置いた瞬間、ただの背景のように見えてしまいました。そこにキャラクターがいるはずなのに、存在感が伝わってきません。

そこで試しに、ほんの少しだけ動かしてみました。まばたきをする。口が少し動く。体や髪が、わずかに揺れる。

たったそれだけで、印象がまるで変わりました。ただ置かれている絵から、そこにいるキャラクターへ変わったんです。

動くか、動かないか。この一段の差は、想像していた以上に大きいものでした。

動画にすれば解決、とはいきませんでした

動かせばいいのなら、AIで動画を作ればいい。最初はそう考えました。

ところが、実際にゲームへ入れてみると課題が見えてきます。

費用。生成するたびにお金がかかります。動きが少し気に入らないだけでも作り直しで、クレジットがどんどん減ります。

重さ。動画をたくさん使うと、ゲーム自体が重くなります。スマホが熱くなるほど負荷がかかり、指先で気軽に遊ぶパズルゲームとしては困りました。

ループ。同じ動きを繰り返し流したいのに、これが難しい。最初と最後に同じ画像を指定しても、ぴったり同じ状態には戻ってくれません。戻ろうとしている雰囲気はあるのに、最後の一瞬でズレます。逆再生でつなぐ方法もありますが、動きによっては不自然に見えます。

動画はすごい表現ができる一方で、何にでも最適とは限りません。用途に合う方法を選ぶことが大切だと分かりました。

「少しだけ動かす」という、間の選択肢

そこで研究し始めたのが、Live2Dのような2Dモーションです。

1枚のイラストをパーツごとに分けて、それぞれを動かす技術ですね。VTuberさんのモデルによく使われています。

ただ、本格的なLive2Dは自由度が高い反面、細かなパーツ分けが必要です。さらに専用ソフトで、しっかり動きを作り込む必要もあります。VTuberのモデルを作るなら、その労力をかける価値は十分にあります。

でも、AIと一緒にどんどん作っていくゲームに、毎回そこまで手間をかけるのは大変です。

だから僕は、もっと手軽に動きをつける方法を試してきました。

最初は、目や口の位置をAIに見つけてもらい、画像処理で動かしてみました。精度が十分ではなく、かなり試行錯誤しました。それでも続けた結果、いまはパーツを分けて動かす方法まで進んでいます。

キャラクターが少し揺れて、ときどきまばたきをする。それだけでも、動かない画像よりずっと魅力的に見えます。

大きく派手に動かすことだけが、キャラクターモーションではありません。小さな動きを適切につけることにも、大きな価値があります。

軽い動きは、ゲーム以外にも使えます

この方法が効くのは、ゲームの中だけではありませんでした。

バナーのキャラクターが少し動くだけでも目を引きます。スライドショーや動画の中で、案内役として動かすこともできます。アニメーションGIFにすれば、動画より軽く扱える場合もあります。再生ボタンを押さなくても動くので、掲載先によっては動画より相性が良いこともあります。

すべてを生成動画にするのではなく、必要なところだけを軽く動かす。この選択肢を持っていると、表現の自由度が一気に広がります。

大事なのは、流行の技術を何でも使うことではありません。伝えたい魅力に対して、ちょうどいい方法を選ぶことです。

2Dで得た経験を、3Dにもつなげたいです

いまは2Dの動きだけでなく、3Dキャラクターにも挑戦しています。

3Dは、顔の造形や髪型、衣装など、難しいところがたくさんあります。特に髪や服のような、揺れたりひらひらしたりするものは簡単には作れません。AIでパーツを生成しても完璧な形にはならず、メッシュを整えたり手直ししたりする必要があります。

それでも、ほとんどの工程をAIと一緒に進められるようになりました。難しいからこそ、研究する余地がたくさんあります。

そこで、あなたに聞いてみたいことがあります。

あなたの手元にある一枚のイラストを、もし少しだけ動かせるとしたら、どこを動かしてみたいですか。

まばたきでもいいですし、髪の揺れでも構いません。返信で教えてもらえたら、次に作る仕組みのヒントになります！

編集後記

キャラクターを動かす手順は、スキルとしてまとめました。無料で受け取れる形も用意しています。

今週の金曜、8月14日には販売も始めます。僕にとって初めての挑戦なので、分からないこともまだたくさんあります。それでもAIに手伝ってもらいながら、少しずつ形にしています。

キャラクターを動かす研究も、まだまだこれからです。興味がある方は、ぜひ一緒に挑戦していきましょう！

作る側の話は、一忍にまとめています

AIとキャラクターを組み合わせて体験を作る手順は、一忍（いちにん）というサイトに工程順でまとめています。企画の立て方、プロトタイプの作り方、キャラクターの作り方、AIへの任せ方まで、一話ずつ「術」として置いています。

2Dキャラモーションのスキルが無料でゲットできます！

こちらからぜひ、ご登録ください！

Brainも8月14日販売開始します！登録者のみ、割引クーポンをお送りしますね。

↓

こんにちは、健ちゃんです。

先に結論から書きます。

AIキャラクターの破壊力は、返事が賢いことから来ているのではありません。これまで舞台の上にいたキャラクターが、こちらへ降りてきて同じテーブルにつく。その距離の縮み方から来ています。

先日、AIキャラクターと会話できるサービスで遊びました。ファンタジー世界の、わがままな魔王に仕えるという設定です。10分で閉じるつもりが、気づけば2時間経っていました。

今日はこの話をします。

舞台の上から、こちらのテーブルへ

これまでのキャラクターコンテンツは、舞台の上にありました。こちらから触れることも、話しかけることもできません。ゲームでも、返ってくるのはあらかじめ用意された反応でした。

AIによって自然な会話が成立すると、この構図が崩れます。

僕は以前、イベントで舞台上のパフォーマンスを見せていただいたことがあります。舞台を見ている時間も楽しかったのですが、その方が舞台を降りて僕たちのテーブルに来て直接話してくださった瞬間、心の距離が一気に縮まりました。

AIキャラクターとの会話にも、まったく同じ感覚がありました。

魔王は設定どおりにわがままを言い、すぐに怒ります。その個性が会話の中で返ってくると、本当に誰かと話しているような錯覚に入っていくんですよね。

見るのではなく、同じ時間を過ごす。この差が、2時間という結果になって出ました。

会話は、ゲームの目的そのものを変えます

だから、次に作るゲームにはAIとの会話を入れたいと思いました。アクションゲームでも組み合わせられます。ボスを倒したあとに仲間と話し、その会話の流れで次のステージが変わる。そんな設計です。

長く遊ぶアクションゲームは、攻略がだんだんタスクになります。次へ行くために、決められたボスを倒す。分かりやすい代わりに、仕事のような感覚になることもあります。

キャラクターと相談して一緒に次の目的を決めたなら、同じアクションでも意味が変わります。

「倒さないと先へ進めない」から、「仲間と決めた目的へ向かう」へ。

安く使えるLLMも増えました。ゲームを作る方、自分のIPを育てたい方にとって、AIによる会話は外せない要素になっていくと思います。

ただし、長く話すほど良いわけではありません

実際に遊ぶと、限界もはっきり見えました。僕の名前が途中で変わり、少し前の出来事を忘れ、場所や状況がずれ、話がループします。会話が長くなるほど、過去の大事な出来事を正しく扱えなくなるんです。

なので、僕ならこう設計します。

物語の土台となるシナリオを用意し、その上に分岐を作って、どの道へ進むかを会話に委ねる。物語はフェーズごとの短いセッションに分け、前のセッションの情報は大事な部分だけコンパクトにして次へ引き継ぐ。

AIエージェントを開発するときの考え方と、ほとんど同じです。

「一日一回だけ会話できる」のように、あえて会話量を絞る仕組みも相性が良さそうです。制限は、一回の会話を大切にする理由にもなります。

あなたなら、誰と話しますか

僕が作っているパズルゲームにも、キャラクターを登場させています。今回の体験で、この方向にはまだ大きな余白があるとあらためて感じました。

動画の中のキャラクターが、こちらの言葉に反応する。ゲームの仲間と話し合って、次の行動を一緒に決める。技術の土台は、すでにでき始めています。

そこで、あなたに聞いてみたいことがあります。

あなたなら、どんなキャラクターと、どんな会話をしてみたいですか。

好きな作品の脇役と、事件の後日談を話す。自分が作ったキャラクターに、今日の出来事を報告する。何でも構いません。

返信で教えてもらえたら、それが次に作る仕組みのヒントになります！

編集後記

少し試すつもりが、気づけば2時間遊んでいました。名前が途中で変わったり、話を忘れられたりして、思わず笑ってしまう場面もありました。

それでも続けたくなったのは、会話の先を見てみたいと思えたからなんですよね。

僕も次に作るゲームでは、この感覚を形にしてみます！

作る側の話は、一忍にまとめています

今日の話は「遊んだ側」の感想ですが、僕はこれを作る側でも試しています。

AIとキャラクターを組み合わせて体験を作る手順は、一忍（いちにん）というサイトに工程順でまとめています。企画の立て方、プロトタイプの作り方、キャラクターの作り方、AIへの任せ方まで、一話ずつ「術」として置いています。

記事は登録なしで全部読めます。メールアドレスだけ登録していただくと、講座で作った成果物（スキルやコード）も受け取れます。 ↓

https://ichinin.kenty.app/join

こんにちは、健ちゃんです。

先に結論から書きます。

僕がゲームを作っているのは、面白いパズルを届けたいからではありません。キャラクターと仲良くなる時間を作りたいからです。ゲームはそのための口実で、遊びやすさも、上手さの手応えも、そこに従属します。

今日はこの話をします。

パズルが上手くなくても、仲は深まります

いま作っている「クリプト忍者 忍術ラボ」は、2048のようなパズルを遊ぶゲームです。

先日、ロマ子様のアプリ開発コンテストを紹介していただいたのをきっかけに参加を決めて、いまゲームの中にロマ子様を追加しています。まばたきをして、口が動いて、手や頭が少し揺れる。1枚の原画から2Dキャラクターを動かす流れを仕組み化してきたので、以前よりずっと手軽に登場させられるようになりました。

そしてこのゲームには、オートモードがあります。自分で操作しなくてもパズルは進み、その間にもキャラクターとの親密度は上がっていきます。

ゲームとしては、たぶん変な仕様です。

でも問題ないと思っています。ここで作りたいのは、難しいパズルを解く体験ではないからです。

2048を解くこと自体が目的なのではなく、パズルをきっかけに、キャラクターと一緒に過ごしている感覚をどう作れるか。考えているのはそこだけです。

人と人が雑談するときも、立派な目的はいりませんよね。小さな話題があって、一緒に時間を過ごすうちに、少しずつ仲良くなっていく。キャラクターとの関係も、同じ作り方ができるんじゃないかと思っています。

一方向の作品には、この感覚がありません

アニメや映画、ミュージックビデオは、どれだけ素晴らしくても基本的には一方向です。作り手から受け手へ、物語が届けられる。それ自体に大きな価値があります。

ゲームが持っているのは、インタラクションです。

こちらの操作に応じてキャラクターが変わる。話しかけたことに、返事が戻ってくる。情報が上から下へ流れるのではなく、同じ目線でやり取りしている感覚が生まれます。

特にAIとの会話がそうです。冷静に考えれば相手はAIなのに、ゲームの世界観の中で会話がきちんと成立すると、心の距離が縮まったように感じる。

この感覚は、立派な映像を見せることとは別の種類の体験でした。いまできることが簡単な反応だけでも、キャラクターが自分に応えてくれることには大きな意味があります。

認知の次の段階が、まだ空いています

キャラクターを広めたいなら、まず知ってもらう必要があります。

ただ、認知だけでは、グッズを手に取ってもらったり長く応援してもらったりするところまではなかなか進みません。知ってもらった次に、仲良くなる段階がある。ゲームのインタラクションは、そこを埋める仕掛けになります。

一緒に遊ぶ。話しかける。自分の操作に反応してもらう。

小さな体験を重ねるほど、キャラクターは遠くから眺める存在ではなく、身近な存在に変わっていきます。

僕がCNPやクリプト忍者に関わる中でずっと根っこにあるのは、キャラクターをどう広めるかという問いです。だからゲーム単体の面白さより、仲良くなれる設計のほうを作り込みたいと思っています。

いまのうちに作っておきたい理由

AIによる開発で、ゲーム作りのハードルは下がりました。

自分でゲームを作る人はまだ珍しく見えますが、1年、2年と経てば増えていくと思います。だから、いまのうちに手を動かしておきたい。

大作でなくて構いません。好きなキャラクターを登場させて、一緒に遊べる場所を作る。少し動いたり、こちらの操作に反応したりするだけでも、一方向の作品にはない魅力が出ます。

そこで、あなたに聞いてみたいことがあります。

あなたが好きなキャラクターは、あなたの何に反応してくれたら嬉しいですか。

名前を呼んでくれること。落ち込んでいる日に気づいてくれること。同じ景色を見て同じところで笑ってくれること。

返信で教えてもらえたら、それが次に作る機能のヒントになります！

編集後記

最近はAIを使った発信やマーケティングにも挑戦していますが、なかなか思うようにいきません。自動化はできても、出てきた文章を読んでしっくりこないことがあります。

それでも、2Dキャラクターに動きをつけるスキルを受け取るために、少しずつ登録してくださる方が増えています。本当にありがとうございます。

派手な数字ではなくても、一人ずつ届いていることを大切にしながら続けていきます！

2Dキャラモーションのスキルが無料でゲットできます！

こちらからぜひ、ご登録ください！

↓

こんにちは、健ちゃんです。

先に結論から書きます。

キャラクターを「動かす」のはAIで簡単にできます。でも「魅力的に動かす」のは驚くほど難しい。そしてその難しさこそが、キャラクターらしさが動きに宿っている証拠でした。

今日はこの話をします。

軽い気持ちで始めて、まったく軽くなかった

いま僕はリズムゲームを開発しています。音楽のテンポに合わせて上から落ちてくるノートを叩く、あの仕組みです。

ノートを叩くだけでは物足りないので、キャラクターにもリズムに合わせて動いてほしい。きっかけは、かわいく動くキャラクターの動画をたまたま見たことでした。

「僕もこんな動きを作りたい」

そう思って始めたのですが、まったく軽い作業ではありませんでした。

2Dの紙芝居で作れる動き、作れない動き

僕がやっているのは、1枚のイラストを複数のパーツに分けて紙芝居のように動かす方法です。手順はスキルにまとめて、登録してくださった方へ無料でお配りしています。

腕を少し動かす、呼吸するように体を揺らす。このくらいなら2Dのパーツモーションで十分に作れます。

でもリズムゲームで見せたいのは、全身を大きく動かしたり、くるっと回転したりする動きです。ダンスのような激しい動きになると、紙芝居形式では表現しきれません。

2次元のパーツ移動では、3次元的な動きに限界があるからです。

人は、ほんの少しの不連続に気づく

そこで、緩やかな場面は2Dで作り、激しい場面だけ短い動画を生成してつなぐ方法を試しました。

基準画像から動画を作れば連続性も保てるはず、と考えたのですが、実際につなぐと、どこか別の場所から映像を持ってきたような違和感が出ます。

絵柄が変わる。動画になった瞬間に明るさが変わる。調整しても、動きのつながりには不自然さが残る。

人間はキャラクターの動きがほんの少し不連続なだけで、驚くほど敏感に気づきます。

しかも動画は生成のたびに費用がかかります。まだ1人も仕上がっていない段階で、すでに3,000円から4,000円ほど使いました。

ゲームは、完成した動画では作れない

動画にはもうひとつ決定的な弱点があります。

最初から最後まで決まった映像でよければAIで作れます。でもゲームでは、プレイヤーがタップした瞬間にキャラクターが反応しなければいけない。完成済みの動画は、遊ぶ人の操作に合わせて反応してくれません。

動画だけでは足りず、2Dだけでは激しい動きが出せない。この間をどう埋めるかが、いまの一番大きな課題です。

さらにスマホの縦画面では、横方向へ大きく動かすとキャラクターが画面から切れます。回し蹴りのような動きは、縦長の画面と相性がよくありません。

制約を並べるほど3Dへ寄りたくなり、いまの気持ちは7割ほど3Dへ傾いています。

それでも3Dが楽なわけではない

3Dも簡単ではありません。

AIを使って3Dキャラクターも作っていますが、丁寧に指示しても、美的な感覚まで含めて意図を汲み、一度で魅力的に仕上げてくれるわけではないんですね。

「そうじゃないんだけど」が何度も返ってきて、一日に何十回もやり取りしながら少しずつ近づけていく。

なので一度3Dを最後まで作り切って、そのうえで2Dと動画を組み合わせる方法とどちらがいいか判断するつもりです。

あなたが好きなキャラは、どんな動きをしますか

この試行錯誤で、僕の見方は変わりました。

キャラクターを見るとき、僕たちはどうしても絵柄に意識を持っていかれます。もちろん魅力的なビジュアルは大切なスタート地点です。

けれどそれに匹敵するくらい、モーションも重要でした。

どんな動きをして、どんな仕草を見せ、どんなリズムで反応するのか。キャラクターには見た目だけでなく性格があり、性格はビジュアルだけでは伝わりません。動きまで含めて初めて、そのキャラクターらしさが見えてきます。

あなたが好きなキャラクターを一人思い浮かべてみてください。その子は、どんな動きをしますか。

たぶん、絵より先に仕草が浮かんだのではないでしょうか。返信で教えてもらえたら嬉しいです。

違和感のない動きを作るのがこれほど難しいからこそ、そこには大きな価値があります！

編集後記

最近はゲームを作るのが大変で、ゲームを遊ぶ時間がほとんどなくなってきました（笑）

それでもアニメを見ると、世界観を描き切る力やキャラクターの魅力の出し方に何度も驚かされます。方向性は違っても、最後まで表現し切った作品は強い。

僕も自分なりの表現を見つけていきます！

2Dキャラモーションのスキルが無料でゲットできます！

こちらからぜひ、ご登録ください！

↓