見出し画像

【第3弾】1人でAIの"会社"を回す。Skill・Script・Runbook・AI推論の四位一体で映像制作まで届いた話‼️

こんにちは!AIクリエイターのinstkoniです。



Claude Code を毎日仕事に使い倒している副業クリエイターで、並行してYoutubeでAI音楽チャンネル「異世界の音楽家 / AI Motion Musics」も運用しています。







【記事概要をPodcastでも聴けます‼️】

 

 


 

昨日決めたルールが、今日また守られていない。
この感覚を一度でも経験した人に読んでほしい記事です。




⚠️「AIはルールを足せば賢くなる」は嘘でした。
  足すほど、守れなくなっていきます。

 

 

 

この記事は「AI秘書シリーズ」の第3弾です。
(注)タイトルに「AIの会社」と書いていますが、あくまでも個人用途です。





💡普段行っているAIモデルとの壁打ちの結果を、RPGのように経験値として取り入れてどんどんレベルアップしていく‼️これが、AI秘書のメリットです。≈

今回は運用でわかったことがたくさんありますので、それをみなさんにシェアします‼️





今回の記事だけでも楽しんでいただけると思いますが、より深くご理解いただきたい方は、シリーズ全体をご覧ください‼️

大変ご好評をいただいております‼️

 

 


さて、前後編を書いたのは数ヶ月前のこと。




あのときは「5部署・AIエージェント数体で動いている」という状態でした。

🤖今は「6部署・エージェント約30体・スクリプト約140本・Runbook約30本」という規模になっています。

数えていませんでしたが、いつの間にかすごいことになってしまっています・・。





AI秘書⁉️会社⁉️…何それ⁉️

という方のために、ウチのClaudeCodeが利用するウチの会社データの現在地をイメージしやすいようにお見せします‼️



難しく考えなくていいですよ😊

ClaudeCodeの「スキル」という機能を使った、まぁいってみれば、テキストの集まりです。





【会社概要/部門紹介(2026年7月版)】

「.company」配下が部署ですね。6部門あります。「mv-studio」が追加になっています。






【AIエージェント(社員)紹介(2026年7月版)】

写しきれないくらいあります。。時折バックアップ取られていますね。
大きな変更を行う時はバックアップとらせています。影武者的な?



ちょっと全貌が見えなかったので、秘書にエージェント一覧を出してもらいました。


まだ稼働していないエージェントもいます。働いていないので窓際族ですかね(笑)
このmdファイルごとがAiエージェント1名ごとだと思ってください。





ただ、数が増えた話がしたいわけじゃありません。今回は「数が増えるにつれてぶつかった壁と、そこから見えてきた設計思想」を渡したい。





それが今日の本題です。語る内容を先にネタバレしておきますね。👇
ではいってみましょう〜〜〜〜〜‼️

AI秘書第3弾の全体構成図:四位一体運営の概念図




  


 


第1章:AIに任せる2つの極端は、どちらも失敗した😨

先程書いた通りAI秘書運用の根幹は「育てること」だと僕は思っています。





だから、ある程度形になったら「とりあえずAIに投げてやらせてみる」という段階は、誰もが通る道だと思います。




問題は、その先に来る「もっとうまくやろう」の2つの罠です。

 

 

 

 

🟢 なぜか欠落するルールたち:毎回「説明が必要」になる

最初に試したのは、Claude Codeに「これやっておいて」と投げるだけのスタイルです。





先にお伝えしますがフローを変えなかったらある程度の品質は保たれます。

でも「改善ルールを追加していくとなぜか不安定」になっていくという僕の日々の使い方でこの現象がでました。




⚠️👤「あれ?なんか急に品質が落ちたぞ?」
⚠️
👤「ん?調査を依頼したのになんでこのレベル・・?」
⚠️
👤「この間作成したワークフローが守られていない?」

モデル自体の問題(LLMは常にアップデートがかかっているので)でモデルが不安定になることがありますが、この徒労感は一度は経験すると思います(;´д`)





僕のAI会社(AI秘書)の運営では、下記の方針を入れて動かしています。

📚「ユーザとの対話の中でルール化が必要なものが登場した場合は、毎回会社のグローバルルール、部門運営のルールを追加してください」

こういれていると、AI秘書や担当からルール化の提案が壁打ち完了ごとに行われます。




欠落するたびに「使いこなせていない僕が悪いのかな」と感じていました。でも後で分かる。問題は僕じゃなく、設計の方でした。

 

 

 

🔵 全部スクリプトでガチガチ化の失敗:例外で止まる

逆のアプローチもやりました。曖昧な点があるなら、「ならばすべてコードで固めてやる」と、Python スクリプトを量産する方向です。




💡単純で推論がいらないものはスクリプト化が功を奏します。

Note記事の下書きの単純投稿、Podcastの作成など、単純なものはいいです。




スクリプトのオペレーションをAIエージェントにやらせていると、急に品質が悪くなることがあります。




例えば、僕の場合ですが、「インフォグラフィック(ウチのNoteで出てくる解説系のイラスト)の作成」です。





作り方自体はテンプレ化されていますが、それがブレブレになってきて安定しなくなりました。

【作り方は単純明快】
📖記事の下書きを読み込んで、作成プロンプトに組み込む
📖参照リファレンス画像を使って、ホワイトボードを使った解説を行うように視聴者にわかりやすくサマリーを書く

実際のプロンプトはもっと複雑ですが、概要だけお伝えするとこんな感じ。




ボツになったインフォグラフィックの例(まだマシ)
のものを貼り付けますね。これはスタイルが守られてなかったからボツになったもの。




(とりあえず一例)スタイルが「ホワイトボード→黒板」に変わっている。
キャラが別人、内容が料理レシピになったこともあった。





このインフォグラフィックの生成スクリプトは、僕がバイブコーディングをやり始めた初期作ですが、本当に使えるので、色々と使いまくっています。




⚠️ただ、AIエージェントが誤解して、「Note編集用のルール」「他のルール」を混同して「既存ルールが見事に崩壊」するという矛盾が発生し、関係の無いルールをNote用インフォグラフィックに適用してしまったんです。

スクリプトは「決定的な動作を保証する」もので、「判断を代替する」ものじゃない。





あとでわかったのは、これらを行使するAIエージェントも悪く無い。
悪かったのは、そのAIエージェントが使う「ルール」のほうでした。

AIに任せる2つの極端はどちらも失敗した。




僕がやった失敗談を次章でお伝えします。

 

 

 


第2章:失敗するたびルールを足したら、AIが守れなくなった☠️

失敗から学ぼうとして、次に取った行動は「ルールを書き足す」でした。
これが、いちばん大きな失敗でした。

 

 


👤「ルールを増やしていけば、AIはもっとうまく動くんじゃないの?」

直感的にはそう思いますが、整備の仕方が問題だった。実態は真逆でした。


 

 

 

🟣 ルールが733行になったときに破綻が起きた

うまくいかない→ルールを足す」を繰り返した結果、こういう状態になりました。

📗 最適化前のサイズはこうなっています👇
✅ルート規約(CLAUDE.md):733行
✅編集部規約:595行
✅スタイルガイド:608行
✅Memory ファイル:87ファイル構造化 + MEMORY.md 索引89件

数字で見ると「整備が進んでいる」みたいに見える。
でも現場では違いました。





エージェントが全文を読みきれない。長すぎて注入できない。





前半のルールと後半のルールが矛盾していても誰も気づかない。そういう状態になっていきました。なんか人間の会社みたいでしょ⁉️

 

👤「733行のルールを全部頭に入れて動けるAI、そもそも存在するの?」

人間はそもそも無理ですが、AIはちゃんと決めればできるかもしれません。
すべてのコンテキストを読み込ませて対応させるのであれば、skillsを使う旨みは無くなります。


 

 

 

🔴 ルールは足すほど「軽く」なる

ここで気づいたこと。「ルールは足すほど、1行あたりの重みが軽くなる。」





紙の上では増えているのに、現場では守られなくなる。本当に人間の会社構造みたいでしょ?





分厚い社内規則集を渡された初日、何ページ目まで読みましたか。AIも同じです。受け取る量が増えるほど、1つ1つへの注意は薄れていく。

 

 

 

✅AIに賢く動いてほしいなら、渡す情報の"総量"を減らして、"文脈の密度"を上げるしかない。

この逆説を体験で理解したとき、設計が変わりました。

 


 

 

ルールを足しすぎると現場が混乱するのは人間世界でも同じですね。



 

 

 


第3章:この問題への解決策は「整理・最適化」と「Runbook化」だった‼️

ではでは、膨れたルールをどう整理するか。



⚠️答えは「役割ごとに置き場を分ける」でした。
⚠️具体的には、「Skill・Script・Runbook・AI推論」これをしっかりと定義してあげることが必要
僕が「四位一体」と呼んでいる設計です。

本文では5つの要素が出てきますが、Memory は四位一体の「土台」に当たるもので、
4つとは別軸で整理しています。


 

 

 

👤「Skill・Script・Runbook・AI推論って具体的に何が違うの?」

それぞれ、担う仕事がまったく異なります。


 

 

 

🟢 Skill:「どう作るか」の正本

Skill は、特定の成果物をどう作るかを書いた技術仕様書です。
僕の環境では現在14個あります。



📖動画プロンプトの組み方、楽曲制作のSunoへの指示形式、SNSコピーの設計法。「誰がやっても同じ品質になる」ためのレシピです。

💡 人間だけでこれを実現しようとすると、できる人への属人化が起きる。
Skill はその属人化をAIに分散させる仕組みです。




コードでも、人間向けの手順書でもない。AIが読んで再現できる粒度で書かれている点が肝です。


 

 

 

🔵 Script:「判断しなくていい処理」を確実に動かす

Script は Python などで書いた自動化コードです。141本あります。




🤖「Note記事の自動投稿」「インフォグラフィックの生成」「X への公式APIを使った投稿バッチ処理」などなどなど…。

「毎回同じ動作を保証したい」かつ「判断は要らない」処理に絞って Script に任せます。




第1章で「全部スクリプト化」が失敗したのは、判断まで Script に投げていたからでした。




判断を外に出したことで、Script はようやく本領を発揮しました。

 

 

 

🟣 Runbook:「どの順で、どこで止まるか」の地図

Runbook は、工程順と品質ゲートを定義した文書です。現在36本あります。




📚「Step 1→Step 2→Step 3、Step 2.5 で品質チェック通過しないと先に進めない」という構造を書きます。

エージェントへの命令文じゃなく、工程全体の地図として機能します。



初期段階では、Runbook なんぞありませんでした。




AIには全 Step が「等価」に見えていて「なぜこの順番なのか」を書いたことがなかったので、AIが勝手に Step をすっ飛ばしていた。





品質ゲートを書いてから、AIが自分で「ここでは止まる」を判断できるようになりました。


 

 

🟠 AI推論:「想定外」を受け止める

Script に「例外処理を書き切る」ことは実質不可能です。どんなに精密なコードも、想定外の事態は起こりえます。





🤖エージェントは現在30体。lead / worker / simulator という階層で、worker が生成し、lead が120点 QC し、simulator が品質を採点します。

120点レビューというのを必ず設けています。100点だとサボるところを120点まで引き上げることで最低品質のレベルがあがる気がしています。場合によっては200点レビューを行うことも。





「想定外は AI に投げる」という設計にしてから、スクリプトが止まる頻度が大きく下がりました。





ちなみに最初は editor と worker の2体からスタートしました。1工程を2体で回すだけでも、精度は変わります。



 

 

 

⚪ Memory:「毎回ゼロから説明しなくていい」土台

四位一体の土台には Memory があります。




📙失敗した事実・学んだルール・過去の判断基準が87ファイルに構造化されていて、MEMORY.md の索引89件から引けるようになっています。

これが「毎回最初から説明しなくていい」を実現している仕組みです。


 

 

 

📗 四位一体+Memory の構造です👇
 ✅Skill = どう作るか(技術正本)
 ✅Script = 判断不要な処理(決定的な自動化)
 ✅Runbook = 何をどの順で、どこで止まるか(工程の地図)
 ✅AI 推論 = 想定外・採点・例外処理
 ✅Memory = 失敗と判断基準の蓄積(土台)

ルールを全部 CLAUDE.md に書くのをやめて、役割ごとに分散させた。
それだけで、AIが「今やるべきことだけ」を受け取れるようになりました。

 

  

正直、「こんなシンプルなことで変わるのか」と驚いたほどです。




整理の前後で、AIが返してくる内容の一貫性がまるで別物になりました。これが一番、僕の中で腑に落ちた瞬間です。

 



👤「この5つ、どこから手をつければいいの?」

最初は「判断が要る仕事」と「判断が要らない仕事」を整理しましょう。それが Skill/Script とAI推論分離の入り口になります。




次に「どの順で・どこで止まるか」をメモして、その内容についてAIと壁打ちを行ってください。





それらをまとめることで、自分のワークフローがきっと Runbook に落とし込まれていると思います。

四位一体の層構造図:Skill・Script・Runbook・AI推論・Memoryの関係

 

 



第4章:Runbookを使って、1本の動画が、どう生まれたか(Abyssal Covenant)

これまで書いてきた経験を使って、いよいよクリエイティブ領域を社内に組み込もうと映像制作部を立ち上げました。




パイロット作品は別作品を使って、ゼロからAI秘書と壁打ちしながら作成を行い、その経験を活かしてRunbook化しています。






次にそのRunbookを使って、旗艦作品「Abyssal Covenant(深淵の誓約)」を実験的に作成しました。





こだわりがあるので、全ては自動でやらせていませんが、60%程度はワークフローとして機能しています。




それでは、工程を実際に追います。


「深淵との誓約を交わす少女」の物語で、約60秒程度のものですが、YouTube Shorts / Instagram /Tiktokに公開済みの実在する作品です。

 




 

👤「実際の現場ではどんな順番で動いているの?」

映像制作の話ですが、「素材→設計→生成→品質確認→配信」の構造はNote記事と変わりません。


 

 

 

🟢 工程1:未使用キャラの自動キャスティング(Script)

僕のAI会社には、MVバンクというキャラクターのアーカイブが社内に存在します。




shared asset部門の担当ですが、 毎日、毎日Midjourneyを使って夜間バッチで「キャラクター/モンスター/武器/世界観」が20種類作成されるようになっています。

朝起きたら出来上がっていて、僕がみていいものを個別ダウンロードします。


ダウンロードフォルダに溜まっていくそれらのキャラクター画像は、夜間にキャラクターシートに自動的に変わるようにさらに仕組みをつくってます。




こんなキャラが毎日作られますが、
どう使っていいかわからないが続きました💦

1枚絵をダウンロードフォルダに残しています(Mac)






翌朝にはこんなキャラクターシートができていて、MVバンクに蓄えられます。






こんな感じで毎日どんどんどんどん蓄えられています。





そこで眠っていたキャラを今回のショート動画(社内ではサーガと呼んでいます。)に引っ張り出すところから始まります。





Script が自動でキャラクターシートを参照し、キャスティングと物語との相性を整理します。※整理後はオーナーに承認を求めてきます。

ヒロインのお嬢様キャラ
彼女の持つ装飾強めの短剣
今回のヴィラン役






🔵 工程2:物語設計(AI推論 + worker-saga、lead 120点 QC)

worker-saga というエージェントが物語の骨格を設計します。





起承転結、転が無音60秒で読めること」というルールが Runbook に書かれていて、lead エージェントが120点 QC を実施します。



このファイルの中にある物語設計が行われ、最終的に工程3で行われる絵コンテのプロンプトや工程5の動画プロンプトもこの中に描かれます。






🟣 工程3:絵コンテ4枚(Script)

4幕15秒ずつ、計60秒の絵コンテを4枚生成します。Script が Genspark に投げて、GPT Image 2 で生成。各コマにショット、カメラ、Energy ラベルが付いています。※絵コンテはあくまでも参考として動画生成AIに読ませます


ACT1
ACT2
ACT3
ACT4





🟠 工程4:楽曲(Skill + Suno 手動)

楽曲設計は Skill(suno-viral-music-creator)が担当します。世界観から歌詞2バージョンを出力し、最終的な Suno への投入は手動です。
AIが設計して、人が投入するという分担。ここはゆくゆく自動化したい。


最初は日本語歌詞のもので作ってましたが、世界観にあわず英語歌詞に。




⚪ 工程5:動画プロンプト(Skill)

Skill(saga-video-prompt-builder)が、絵コンテ4枚をもとに Seedance 用の動画プロンプトを組みます。4幕それぞれに完全版・自己完結のプロンプトが出力されます。


※プロンプトは先ほどのファイルに組み込まれています。
※ここは壁打ち形式でAIと作ってもいいと思います。ストーリーや絵回しとか。イメージがあれば。






🔴 工程6:動画キャンバス(TapNow)での作成 + 手動編集(Filmora)


動画生成モデルはSeedance2を使います。(2026年7月段階では最も優秀なモデルだと思います。)




使いやすいと個人的に感じているのはTapNow (タップナウ)というサービスで、こんな感じでキャンバスが使えます。

僕はTapNowを使っています。公式APiが無いのと工程が複雑なので、ここは手動。





ちなみに下記リンクから登録とサブスク登録したら100Tapisがもらえるようです。5秒程度の簡単な動画なら作れるくらいですが、本気で始められるかたはどうぞ。


ちなみに、僕の作った👆のキャンバスをコピーできるようにしておきました。もし参考にしたければどうぞ〜。
https://app.tapnow.ai/tapflow/view/c8d7cb0c




素材が揃ったら、動画編集ソフトで編集です。ここはAIに任せられないですね。正直まだまだSeedance2の動画生成はガチャなので。。素材のカットと繋ぎ合わせが複雑すぎるんです。

カット、トランジション、調整レイヤー被せで色調調整を行っています。





🔴 工程6:SNSコピー(Skill + 120点採点)

short-video-sns-strategist という Skill が YouTube Shorts・Instagram・X 向けのコピーを設計します。ネタバレ禁止・世界観維持という条件が Skill に書かれていて、simulator エージェントが採点します。

 

 



🟢失敗を活かして明日の創作に備えよ。

動画作成ではかなり失敗がありました。それを包み隠さずお伝えします。

📗 この工程で起きた3つの失敗が、すべて Memory に上がっています👇

💥 失敗1:映像が突然「4分割画面」になった

絵コンテの「2×2グリッドで4カットを並べて見せる」という構成を指示したら、Seedance がそれを「映像そのものを4分割せよ」と解釈しました。

完成した動画を再生すると、画面が4つのワイプに分割されていた。

この失敗の行き先:「2×2 montage 廃止、全画面1枚ずつ高速連続に変更」という判断が Memory に入り、以降のサーガ全作で同じ失敗はゼロになりました。
 
💥 失敗2:「誓約劇」が、無音で流すと何も伝わらなかった

最初の設計は厳かな誓いの場面が続く「誓約劇」でした。BGMをつけると映えるのに、無音60秒で流すと物語の流れが全く読めない。「起承転結の転が読めること」という基準が Runbook になかったのが原因でした。

起承転結の「転」を水中バトル+契約使役というアクション的な転換に作り替えました。

この失敗の行き先:Runbook に「転は無音60秒で因果が読めること」が追加されました。今後のサーガはすべてこの基準で QC されます。


💥 失敗3:「パリィで反撃」と書いたら、敵に背を向けた

動画プロンプトに「敵の攻撃をパリィで受けて反撃する」と書きました。

生成された映像では、キャラクターが敵に背を向けた状態でエフェクトが炸裂していた。「反撃」の意味はあっているが、「どちらを向いて戦うか」が伝わっていなかった。

この失敗の行き先:FACING ロックと STAGING ロック(「敵は正面・キャラは画面左前」等の位置指定)という表現指定が Skill に追加されました。

これ、全部実際に起きた話です。



💡 失敗が「もったいない体験」で終わらないのが、このシステムの肝です。





Skill に記録すれば技術の正本になり、Runbook に書けば工程ゲートになり、Memory に入れれば次回以降の判断基準になる。




この3方向への変換が、1人運営で品質を維持できる理由です。

Abyssal Covenant制作の工程フロー図


 

 
 


最終章:整え続けることが、運営という行為だった

この記事で伝えたかったことを整理します。

 

 

 

📗 この記事で言いたかった、3つのポイントです👇
✅ルールは足すほど守られなくなる。「判断要/不要の仕切り」を1つ作ることが先
✅Skill(どう作るか)・Script(確実な自動化)・Runbook(工程の地図)・AI推論(想定外の受け皿)・Memory(失敗の蓄積)の役割分担が、品質と再現性を生む
✅失敗はSkill・Runbook・Memoryの3方向に変換する。変換先が決まっている失敗は、繰り返さない

「仕組みを作って終わり」ではなく、「整え続けること」が運営です。

 




エージェントが30体になっても、Runbook が36本になっても、根っこにある問いは同じです。

💡 この失敗をどこに記録して、次にどう生かすか」。
  この問いを持ち続けるだけで、失敗が資産に変わっていく。
  それが「整え続ける」ということだと、ようやく実感できています。

 

 

 

⭐️手を動かす仕事はAIへ。人の仕事は「渡し方の設計」に変わる。⭐️




AIが賢くなるほど、人間の仕事は「ゴールを定義して、120点の無茶振りをして、失敗を資産に変える」ことに純化していく。そう感じています。




個人でも仕組みは作れる。設計思想を持って整え続けること。それが、AIの"会社"を回すということだと思っています。





最初の一歩は小さくていい。「判断が要る仕事」と「判断が要らない仕事」を1つ仕切るだけでも、四位一体への入り口になります。

 

 



 

この記事で言いたかった3つのポイント


 

 

最後までお読みいただき、ありがとうございます‼️

 




さて、AIを使っていれば誰でも一度は経験するあの感覚、「昨日決めたはずのことが、また無視されてる」。




あなたが今いちばんそれを感じている場面はどこですか⁉️





ぜひ、コメントであなたの意見を聞かせてください‼️



 

この記事が少しでも「役に立った!」と思っていただけたら、
「スキ」を押していただけると、次の記事を書く大きな励みになります‼️

いいなと思ったら応援しよう!