これは効率化の話ではなく、業務設計の話です

プロンプトをいくら磨いても、出力が安定しない。そんな経験はないでしょうか。私はありました。何度も書き直して、例を足して、指示を細かくして、それでも週によって品質がぶれる。

ある時から、原因はプロンプトの精度ではないと考えるようになりました。問題は「書き方」ではなく「組織の設計」のほうにあったのです。

「AIで定型業務を効率化しました」という記事は、もう十分にあります。この記事はそれとは違う角度から書きます。きっかけは、競合の動向を毎週ウォッチしてレポートとスライドにまとめる、という定型業務をAIに任せる仕組みを作っていたときのことです。プロンプトを何度も書き直し、テンプレートを整え、実行手順を組み立てていくうちに、自分がやっているのはツールの使い方を覚えることではなく、仕事の役割分担と引き継ぎのルールを設計することだと気づきました。

できあがったプロンプト一式を眺めると、それは便利ツールの設定ファイルというより、小さな組織の設計図に見えました。この記事は、その視点で「AIで定型業務を組織化する」とはどういうことかを書きます。プログラムのコードは出てきません。出てくるのは、設計の判断と、その判断が刻まれた数行の指示文です。

題材：週次の競合ウォッチ・パイプライン

具体例がないと設計論は宙に浮くので、題材を一つ置きます。ここでは架空のSaaS企業「Northwind」が、競合のX（旧Twitter）公式アカウントを毎週ウォッチし、その変化を経営層向けスライドにまとめる、という業務を想定します。

処理の流れはシンプルです。

競合アカウントを巡回し、前回からの差分を抽出してMarkdownレポートにする
そのレポートを読み込み、固定テンプレートに差し込んで経営層向けのPowerPointにする

これを毎週月曜の朝に回す。ここまでは、よくある自動化です。面白くなるのは、この2工程を「どう設計したか」のほうです。

なお、この仕組みは Claude Code（ローカルのファイルを読み込ませて、エージェントに実行させるツール）で動かしています。以降に出てくる「プロンプトを読み込ませて実行する」は、すべてこの環境での操作を指します。設計の考え方自体は他のエージェントでも通用しますが、なぜこの設計が素直に成立するのかは、Claude Codeの「ローカルのファイルをそのまま扱う」性質と深く関わっています。

柱1：プロンプトを「従業員」として設計する

最初の発見は、各プロンプトに役割を与えると設計が一気に整理される、ということでした。

分析プロンプトは、競合の投稿を読んで差分と戦略変化を読み解く「シニアアナリスト」です。スライド生成プロンプトは、その分析結果を非技術者に伝わる形に作り替える「資料作成の専門職」です。生成後にスライドを画像化して崩れや差し替え漏れを検査する工程は「QA担当」です。そして、この2つを正しい順序で動かす統合指示文が「マネージャー」にあたります。

マネージャーの仕事で大事なのは、順序を決めることだけではありません。引き継ぎの検収基準を決めることです。実際、統合指示文にはこういう一文を入れています。「ステップ1が成功し、レポートが今日の日付で更新されていることを確認してから、ステップ2に進む。確認できなければ進まず理由を報告して終了する」。

これは組織でいう受け入れ検査そのものです。前工程の成果物が基準を満たさないまま後工程が走ると、一番気づきにくい事故が起きます。たとえば競合の取得に失敗してレポートが更新されなかった週に、先週のレポートから先週と同じスライドが今日の日付で生成される、というような事故です。検収基準を一行入れておくだけで、これを構造的に防げます。

検収基準を入れないと、前工程が失敗した週に「先週と同じ内容のスライドが、今日の日付で生成される」という最も気づきにくい事故が起きます。工程を連結するときは、前工程の成果物チェックを必ず挟んでください。

このマネージャーの実体は、たった数行の指示文です。

以下を順番に実行してください。

1. prompt/weekly_x_competitor_prompt.md を読み込み、指示に従って実行する
   （レポート生成・保存まで）
2. latest.md の作成日が今日の日付に更新されていることを確認してから、
   prompt/competitor_slides_prompt.md を読み込み、指示に従って実行する
   （pptx生成・保存まで）

ステップ1が失敗した場合（latest.md が更新されていない場合）は、
ステップ2に進まず理由を報告して終了してください。

役割分担と引き継ぎ条件が、これだけで表現されています。1がアナリスト、2が資料作成担当の起動で、その間に挟まった「latest.md が今日の日付か確認してから進む」の一文が、部門間の検収にあたります。最後の「失敗したら進まず報告して終了」は、不良品を後工程に流さないためのストッパーです。マネージャーに必要なのは、賢さよりも、止めるべき条件を明示しておくことでした。

Claude Codeであれば、この指示文を ~/.claude/commands/ にカスタムコマンドとして置いておけます。すると毎週の起動が一語のコマンドで済み、マネージャーが常駐している状態になります。設計の言葉でいえば、就業規則を毎回読み上げるのではなく、組織のルールとして常設した、ということです。実際のセットアップや連結実行の手順は、リポジトリのREADME（マネージャー役の実行）にまとめています。

抽象的に言えば「役割分担と検収」ですが、実装に落とすと「各プロンプトに職務記述を書き、統合指示文に受け入れ条件を書く」になります。良い自動化は、良いプロンプトより、良い検収基準でできている。これが最初の柱です。

柱2：記憶を持たない組織を、どう動かすか

ここが、人間の組織との最大の違いです。

AIのセッションは、毎回ゼロから始まります。前回何をどう判断したかを、AI自身は覚えていません。例えるなら、毎週月曜に全従業員が入れ替わる会社です。普通ならそんな組織は回りません。

それでも回るのは、業務知識を人（セッション）ではなく文書に完全に外部化しているからです。何を競合と見なすか、どんな観点で差分を取るか、レポートをどう書くか、スライドをどう組むか。判断のすべてがプロンプトとテンプレート、そして前回レポートという3つの文書に書き出されています。新しいセッションは、この文書を読むことで「先週までの自分」を引き継ぎます。

この構造の効用は、属人化が起きないことです。正確には、属人化したくてもできない。記憶が消える以上、知識を文書に書き出す以外に引き継ぐ方法がないからです。人間の組織が何年もかけて目指す「業務マニュアルの整備」と「知識のサイロ化の解消」が、ここでは前提条件として強制されます。

外部化された文書は、こんな構成で1つのフォルダに集約しています。

competitor-watch/
├── prompt/
│   ├── weekly_x_competitor_prompt.md   # 分析の職務記述（アナリスト）
│   └── competitor_slides_prompt.md     # スライド化の職務記述（資料作成）
├── slides/
│   ├── template.pptx                   # 固定デザイン資産
│   └── competitor_weekly_slides_2026-06-08_w24.pptx
├── latest.md                           # 直近1回分（次回の比較基準）
├── weekly_x_competitor_report_2026-06-08_w24.md
├── weekly_x_competitor_report_2026-06-03_w23.md
└── …（週番号付きアーカイブが履歴として積み上がる）

この一覧そのものが、組織の構成図になっています。prompt/ が職務記述書、template.pptx がデザインの標準、週番号付きのレポートが業務日誌、latest.md が「直近の引き継ぎ資料」を指すポインタです。新しいセッションはこのフォルダを開けば、先週までの組織が何をしてきたかをすべて復元できます。逆に言えば、ここに書かれていないことは引き継がれません。

ここでClaude Codeの性質が効いてきます。Claude Codeはカレントディレクトリのファイルをそのまま読み書きするので、「業務知識をファイルとフォルダに外部化する」という設計が、特別な仕組みなしにそのまま成立します。データベースもサーバーも要らず、フォルダを開けばそれが組織の全記憶になる。ローカルのファイルが主役であるツールと、知識を文書に外部化する設計思想は、もともと相性がいいのです。

だから、運用の途中で見つけた判断は、その場で直すだけでは足りません。必ずプロンプトに書き戻します。「なぜそうしたか」だけでなく「なぜそうしなかったか」も含めて書く。たとえば、あるレイアウトを変えなかったときに、その理由を残しておく。そうしないと、来週の「新しい従業員」は同じ箇所をまた変えようとします。レビューの結論を文書に焼き込むこと自体が、この組織の人事と教育にあたります。

その場で直して満足し、プロンプトへの書き戻しを忘れると、来週の「新しい従業員」は同じ箇所をまた同じように変えようとします。直した内容は、必ず文書側へ反映してください。記憶を持たない組織では、書き戻されなかった判断は存在しなかったことになります。

柱3：見た目にも、論理を通す

設計論というと処理フローの話に寄りがちですが、成果物の見た目にも同じ規律が必要でした。経営層向けのスライドは、見た目が説得力に直結するからです。

最初、スライドは毎回AIにデザインごと生成させていました。これをやめ、良かった1枚を固定テンプレートにして、テキストだけ差し替える方式に変えました。理由は、生成のたびにレイアウトが変わる「デザインのガチャ」を排除するためです。同じ品質を毎週確実に再現するには、デザインを資産として固定し、変動するのは中身だけ、という分離が要ります。

テンプレートを固定したうえで、もう一つ工程を足しました。生成したスライドを毎回レンダリングして目視確認する工程です。差し替え方式の最大の事故は「先週の数字が一箇所だけ残ったまま経営層に出る」ことなので、QA担当の検査をパイプラインに組み込んでおきます。柱1で触れた役割分担が、ここでも効いてきます。

色の使い方にも論理を通しました。象徴的だったのは、強調色の位置です。当初、3項目あるうちの3番目だけに色が付いていました。見た目のリズムとしての装飾で、意味はありませんでした。けれどスライドは重要度順に並べる設計なので、最重要は1番目のはずです。視覚的な強調が常に3番目に付くと、読み手は色のついた項目を「これが一番大事」と読むため、資料の論理と視線誘導が逆を向きます。そこで強調を1番目に移し、「強調＝ここから読む」という意味を与えました。

ここでの設計原則は一つです。視覚の差は、必ず情報の差に対応させる。意味のない装飾は、たとえ綺麗でも誤読を生むので外します。色についても、ダーク面・自社のアクセント・競合各社の識別色・補助色、という意味の体系を決め、それ以外の色は使わないというルールにしました。色が「ここを読め」「これは自社」「これは競合A」と語るようにする、ということです。

締め：この従業員は、改善を提案してこない

ここまで「小さな組織」として書いてきましたが、人間の組織と決定的に違う点が最後に残ります。

この従業員たちは、自分から業務改善を提案しません。 毎週きちんと働き、指示された検収基準を守り、文書化された知識を完璧に引き継ぎます。けれど「この工程、こうしたほうが良くないですか」とは言ってこない。プロセスの改善は、人間が成果物をレビューし、気づいたことを仕様に書き戻すことでしか起きません。

つまり、経営者と人事と監査にあたる役割は、依然として人間側に残ります。AIに渡せるのは「決められた仕事を、決められた基準で、忘れずに実行する」部分まで。「何を仕事と定義し、どの基準で検収し、どう改善するか」を決めるのは人間の仕事です。

だからこの取り組みは、振り返ってみると「AI活用」と呼ぶより「業務設計」と呼ぶほうがしっくりきます。プロンプトを書くことは、記憶を持たない従業員のために職務記述書と就業規則と業務マニュアルを書くことだった。できあがった一式が小さな組織の設計図に見えたのは、実際にそれを設計していたからです。

定型業務をAIに任せようとしている方は、ぜひ一度「これは誰の、どんな役割で、どこで検収する仕事か」という組織の言葉で自分の業務を眺めてみてください。プロンプトの精度を上げる前に、組織の設計を見直すほうが効くことが、案外多いはずです。プロンプトを磨くのに行き詰まったら、書くべきなのは就業規則のほうかもしれません。

本文で触れた仕組みを、架空の題材に置き換えたサンプル一式を公開しています。

リポジトリ全体（プロンプト・テンプレート・使い方）

分析プロンプト（アナリスト役）: weekly_x_competitor_prompt.md
スライド生成プロンプト（資料作成役）: competitor_slides_prompt.md