非エンジニアが Claude Code を使う組織設計 — 経営判断と権限委譲

この記事は、エンジニアではない事業主が Claude Code を使い始め、4 つのプロダクトを実際に実装した一次情報として書いている。「非エンジニアでも Claude Code は使えますか」という問いへの抽象論ではなく、「八雲の代表（非エンジニア）がどう使い始め、どこで詰まり、何を諦め、何を乗り越えたか」を具体的に記録する。

技術的な実装の詳細——CLAUDE.md の書き方、skill の実装パターン、エージェント設計の設計原則——は技術側の記事「非エンジニアが Claude Code を使う組織設計の技術構造」で扱う。本記事ではコードを一切扱わない。

Key takeaway 3 点:

Claude Code は「エンジニアが使うコーディング補助ツール」ではない。非エンジニアが組織の業務設計ツールとして使える段階にある。ただし、その入口設計（CLAUDE.md と skill の整備）を誰が担うかが最大の課題だ。
非エンジニアが実装できた範囲と、エンジニアに依頼すべきだった範囲には明確な境界がある。その境界を事前に引くのは難しいが、事後に振り返ると判断基準が見えてくる。
「Claude Code に投資する」という経営判断は、生産性向上の投資というより、組織の情報処理構造を変える投資だ。ROI は短期のコスト削減ではなく、中長期の意思決定速度と実行力の変化で測るべきだ。

なぜ非エンジニアの事業主が Claude Code を使い始めたか

「エンジニアがいない」という事実から始まった

八雲は 2025 年 4 月、森本拓見 1 名（個人事業主、PM 兼ジュニアエンジニア） に始まった組織だ。当初からエンジニアの採用を試みたが、AI エージェント開発を専業で担えるエンジニアはそう簡単には見つからない。採用を待ちながら、事業を動かす必要があった。

Claude Code との出会いは 2025-07 のことだ。当初は「AI がコードを書いてくれる」という認識だったが、使い始めて数週間で認識が変わった。Claude Code は「コードを生成するツール」ではなく、「意図を伝えると実装まで完結させるエージェント」だった。

非エンジニアの事業主にとって、この違いは決定的だ。コードの生成は依然として「何が正しいコードか分からない」という壁がある。しかしエージェントに「このプロダクトで、この業務を、こういう動きにしたい」と伝えると、設計から実装まで一気に進む。検証と修正の判断は人間がする——この分業が成り立てば、エンジニアがいなくてもプロダクト開発は動く。

2025-07 から 10 ヶ月で 6 プロダクトを実装するという選択

Claude Code を使い始めてから、八雲では以下の 6 プロダクトを順番に実装した。

1. synapse（業務横断エージェント組織） Claude Code 上に責任者エージェント群（@director / @sales-director / @dev-director など）と業務スキル群を組んだ仕組みの総称だ。受注から請求書、議事録、提案書まで業務の多くを担う。最初に実装したため最も試行錯誤が多く、失敗と改善の積み重ねが他プロダクトの基盤になった。

2. montage（動画コンテンツ生成パイプライン） Claude Code エージェントと Remotion（React ベースの動画ライブラリ）を組み合わせて動画コンテンツを量産する仕組みだ。調査から脚本、音声合成、レンダリング、サムネイル生成まで一連の工程をエージェントで分担する。

3. mcluhan（owned media 運用エンジン） 本記事も mcluhan が管理する記事パイプラインで公開されている。記事の構成設計、品質審査、公開スケジュール管理を自動化した。

4. corporate-site（コーポレートサイト） Astro + React + Tailwind で構築したウェブサイト。デザインシステム、SEO 設定、記事 CMS、コンタクトフォームまで含む。mcluhan が管理するコンテンツの公開基盤でもある。

5. medallion（金融データ自動取得基盤） JPX・TDnet・各社 IR から決算短信を毎朝自動取得し、共有スプレッドシートに蓄積する Python ベースのデータ収集ツール。launchd で日次実行している。

6. bateson（汎用 Booking Engine） adapter パターンと tenantId による multi-tenant 設計の予約エンジン。本記事の問い合わせフォーム（/contact）も bateson で動いている。AIネイティブ組織土台の上で展開する事業ラインの 1 つとして、将来の商用展開への扉を保ったまま実装している。

この 6 プロダクトを 2025-07 〜 2026-05 の 10 ヶ月 で実装した。全てにおいて、「エンジニアが書いたコードはほぼゼロ」という状態で動いている。

第 1 軸: skill の安全な委譲 — 何を任せ、何を任せないか

skill とは何か（非エンジニア向けの説明）

Claude Code の「skill」は、特定の作業手順を定義したテキストファイルだ。「この作業をするときは、この順序でこういう判断をして、この形式で出力してほしい」という指示書を書いておくと、エージェントがその指示に従って実行する。

料理レシピに近い。「カレーを作って」という指示だけでは、エージェントは無数の解釈ができる。「じゃがいもは 2cm 角に切る」「玉ねぎは飴色になるまで炒める」「水は 600ml」と手順を定義しておけば、毎回同じ品質のカレーができる。

synapse で最初に整備した skill は、提案書作成スキルだ。「顧客名・要件・金額を渡すと、八雲の提案書フォーマットに沿った draft を生成する」という手順を定義した。最初のバージョンは数週間の試行錯誤がかかったが、一度整備すると非エンジニアのスタッフでも同品質の提案書 draft を出せるようになった。

委譲して安全な skill と委譲すべきでない skill

synapse を運用する中で、委譲できる skill と委譲すべきでない skill の境界が見えてきた。

委譲して安全なもの（決定論的な作業）:

決まったフォーマットへの変換（提案書、議事録、請求書）
情報の収集・整理（スクレイピング、記事の要約、データ整形）
定型的な文書生成（確認メール、進捗レポート、ブリーフ）
品質チェック（文体の統一、禁則語の検出、数値の整合確認）

共通点は「正解が定義できる」作業だ。フォーマットが決まっていて、入力と出力の対応が明確な作業は、skill として定義しやすく、非エンジニアが運用しても安全に動く。

委譲すべきでないもの（判断を要する作業）:

顧客への提案可否の最終判断
契約内容・価格の決定
採用・人事に関わる評価
リスクの定性的な評価
戦略・方針の決定

これらは「正解が文脈によって変わる」判断だ。エージェントに任せると、エージェントは何らかの判断を下すが、その判断の根拠や責任の所在が不明確になる。

montage の例で言えば、「動画の脚本 draft を生成する」は委譲できる。しかし「この動画を公開するかどうか」の判断は人間が行う。生成 AI が作った動画コンテンツの公開承認を全自動にした瞬間に、ブランドに関わるリスクが生まれる。

skill 委譲の段階的な進め方

synapse での実際の進め方を振り返ると、3 段階だった。

段階 1（最初の 1 ヶ月）: 既存の作業をそのまま言語化する 手動でやっていた作業を、そのまま言語で記述する。「提案書を作るとき、何を、どの順序で、どう考えて書いているか」を文章にする。この段階では Claude Code は使わず、自分の思考プロセスを外部化することに集中した。

段階 2（2〜3 ヶ月目）: skill として整備し、自分で試す 言語化した手順を skill ファイルとして Claude Code に読み込ませ、自分で実行して検証する。「意図通りに動くか」「出力の品質は許容範囲か」「どういうインプットを渡せば安定するか」を探る。この段階で多くの失敗があった。

具体的には、blog-tech-write skill が初期バージョンでは「retro 由来の learning」を反映しておらず、出力記事が cluster 整合性違反（business 記事に tech 詳細が混入）を含んだ。対処として A-H の learnings を SKILL.md に encode し、retro と紐づけて skill 自体を改善する仕組みを整備した（参考 commit: 1bcad03 feat(blog-skills): encode A-H learnings）。skill は一度作って終わりではなく、運用から得た学びで update し続ける対象だ。

段階 3（4 ヶ月目以降）: 他のメンバーへの委譲 自分で使えるようになった skill を、他のメンバーが使えるように整備する。操作手順のドキュメント化と、誤操作を防ぐための CLAUDE.md への制約追加が主な作業だ。

この段階で初めて「非エンジニアへの委譲」が成立する。自分だけが使える段階では組織としての価値は小さい。skill が組織のメンバーに広がって初めて、Claude Code への投資が回収できる。

第 2 軸: CLAUDE.md 設計 — 制約と許可の宣言

CLAUDE.md の役割（非エンジニア向けの説明）

CLAUDE.md は、Claude Code に「この組織のルール」を伝えるテキストファイルだ。Claude Code を起動すると、最初に CLAUDE.md を読み込み、そこに書かれたルールに従って動く。

組織に新しいスタッフが入ったとき、「うちではこういうルールで動いています」と伝える入社マニュアルに近い。「この言葉は使わない」「この作業は必ず確認してから進める」「このフォーマットを守る」という規則を書いておくことで、エージェントが勝手な判断で問題のある行動をとるリスクを減らせる。

corporate-site での CLAUDE.md 設計

corporate-site の CLAUDE.md を設計するとき、最初に直面したのは「何を書けばいいか分からない」という問題だった。

エンジニアにとって CLAUDE.md はある程度直感的かもしれない。コードのスタイルルール、禁止するライブラリ、テストの実行コマンドを書けばいい。しかし非エンジニアには「コードのルール」を書こうにも、何が「ルール」なのかが分からない。

突破口になったのは、「失敗してから書く」というアプローチだった。

Claude Code に作業を任せて、意図しない結果が出たときに「これをするな」と CLAUDE.md に追記する。最初は空に近かった CLAUDE.md が、失敗の積み重ねで徐々に厚くなっていった。

corporate-site の CLAUDE.md には今、以下のような制約が含まれている:

ハードコード禁止（フォントサイズ・色・スペーシングは設定ファイルから参照する）
コミットメッセージは英語
作業ブランチは develop（main 直 push 回避）
特定のディレクトリを編集する前に _README.md を読む

これらの制約は全て、一度「やってしまった失敗」から生まれている。CLAUDE.md は「最初から完璧に書く」ものではなく、「失敗して学んだルールを追記し続けるもの」として機能する。

CLAUDE.md 設計は誰が担当するか

重要な点を一つ強調しておく。CLAUDE.md の設計は、エンジニアが担当すべきだ。 しかし CLAUDE.md の運用（追記・更新・管理）は、非エンジニアでもできる。

設計と運用は別の作業だ。

設計とは「どういう構造にするか」を決めることだ。どのルールをグローバル（全プロジェクト共通）に置き、どのルールをプロジェクト固有にするか。制約の粒度をどう設定するか。これらはシステム設計に近い判断であり、組織のドメインを理解している人間が関与すべき部分だ。

運用とは「起きた問題をルールとして追記すること」だ。「この作業をしたら意図しない結果になった」という体験を言語化し、CLAUDE.md に追加する。

synapse の CLAUDE.md は、最初の設計から自分が担当した。非エンジニアではあるが独学でプログラミングを学習しフロントエンドの実装はできる状態だったため、設計の構造判断はできた。一方で CLAUDE.md の本文を書く部分は Claude 自身に実行させた——自分が「こういう構造にしたい」と方針を決め、Claude にその構造で本文を起草させ、内容をレビューして追記・修正する形だ。設計判断は人間、執筆は AI、運用更新も人間という分業が現実的な形になった。

第 3 軸: 段階的な権限委譲 — 3 つの Stage

Stage 1: 読み取り専用（情報収集・ドキュメント生成）

Claude Code が持つ権限の中で、最もリスクが低いのは「読む」権限だ。ファイルを読む、ウェブを検索する、データを参照する——これらは誤操作しても取り返しがつく。

synapse での最初の実装はこの Stage からだった。

具体的には、「競合他社のウェブサイトを調査して、施策の一覧を表形式で出力する」というスキルを最初に整備した。Claude Code はウェブを検索し、情報を整理し、ドキュメントとして出力する。この段階ではファイルの書き込みすら許可していなかった——出力はターミナルに表示し、使う場合は人間がコピーして使う。

この段階で学んだことは、「情報収集の自動化だけでも、実質的な工数削減は大きい」という事実だ。調査レポートを人間が作ると数時間かかっていた作業が、Claude Code では 20-30 分程度 に短縮された。

Stage 2: 提案生成（ドラフト作成・コンテンツ生成）

Stage 2 は「書く」権限の付与だ。ドラフトを生成し、ファイルに保存する。

mcluhan の記事生成パイプラインはこの Stage に相当する。エージェントが記事のブリーフを読み、本文を生成し、指定のディレクトリに Markdown ファイルとして書き込む。人間は生成されたファイルをレビューし、承認すれば公開フローに乗せる。

Stage 2 で最も重要な設計は、「人間が介在するチェックポイントをどこに置くか」だ。

mcluhan では、エージェントが生成した記事には下書きフラグが立つ。このフラグが付いた記事は自動公開されない。人間がレビューして下書き状態を解除することが、公開の条件になっている。エージェントが記事を「書く」権限を持ちながら、「公開する」権限は人間にある——この設計が安全な Stage 2 を実現する。

Stage 3: 実行権限（システム操作・外部連携）

Stage 3 は「動かす」権限だ。外部システムへの書き込み、スケジューラの制御、API の呼び出し。

synapse がこの Stage に相当する。Google Drive へのファイル保存、Gmail からのメール送信、GitHub へのコミット——これらを Claude Code のエージェントが実行している。

Stage 3 のリスクは Stage 1/2 と質が違う。ファイルへの書き込みは基本的に元に戻せるが、メール送信は取り消せない。GitHub へのコミットも、force push で消すことはできるがトレースが残る。外部サービスへの請求が発生する操作も含まれる。

この Stage でのリスク管理を一つ具体的に記録しておく。

synapse で受注後の書類関係を自動化したとき、誤って同じ顧客に請求書を 2 通送ってしまったことがあった。原因は、スクリプトのべき等性（同じ操作を複数回実行しても同じ結果になる性質）の設計ミスだった。一度のコマンド実行で送信フローが 2 回走る状態になっていた。

2026 年初頭に、自動送信スクリプト（synapse の前身）で同一顧客への二重送信が発生した。原因はべき等性の設計不備で、一度のコマンド実行で送信フローが 2 回走る状態になっていた。発覚後すぐに顧客に状況説明と謝罪、二重請求の取り消しを行った（顧客の社名はここでは伏せる）。この失敗を受けて、後に synapse として整備する際に「送信前確認ステップ」を CLAUDE.md ルールに昇格させた。

この失敗から、Stage 3 の操作には「送信前確認」ステップを必須にするというルールを CLAUDE.md に追記した。「外部への送信操作の前に、送信内容を人間に確認してから実行する」という制約だ。操作の自動化と、最終確認の人間化を組み合わせる設計になった。

各 Stage の移行条件

Stage を移行するタイミングの判断基準を整理する。

移行	条件
Stage 1 → Stage 2	Stage 1 の出力を 2 週間以上継続して使い、品質に問題がないと確認できた
Stage 2 → Stage 3	Stage 2 の生成物を人間がチェックせず使えると判断できた業務が出てきた

この基準は定性的だが、「使ってみて問題がなかった」という体験の積み重ねが前提になる。信頼は実績によって生まれる。

リスク管理 — 非エンジニア活用の安全網設計

コスト暴走の防止

Claude Code は使った分だけトークン（処理量）のコストがかかる。非エンジニアが使う場合、「どれだけ使うと費用がいくらになるか」の感覚を掴むまでに時間がかかる。

実際に経験した問題として、synapse の開発初期に、ループ処理のバグでトークン消費が急増したことがあった。Claude Code が同じ処理を繰り返し実行し続け、想定外の費用が発生した。

この体験からルールを設けた。月次でトークン消費を確認するレビューを設け、月次の上限を設定している。月額 10 万円 を超える場合は使い方を見直すトリガーにしている。

コスト管理の基本は「使った量を見える化する」ことだ。Anthropic のダッシュボードには使用量とコストが表示される。これを定期的に確認する習慣を作ることが、最初のコスト管理だ。

誤操作・意図しない実行の防止設計

非エンジニアが Claude Code を使うとき、最も怖いのは「何が起きているか分からない状態で実行する」ことだ。

この問題への対応として、以下の設計を採用した。

1. 実行前の計画確認（事前計画パターン） 大きな作業の前に、Claude Code に「これから何をするか」を先に書き出させる。実装を始める前に計画を確認し、「意図と合っているか」を判断してから実行を許可する。

2. 影響範囲の限定（スコープ制限） 作業の委譲時に「このディレクトリ以外は触らない」「このファイル以外は編集しない」という明示的な制約を付ける。Claude Code は指示された範囲を超えて作業することができるため、意図的に範囲を狭める必要がある。

3. 取り消し可能な設計（Git ブランチ戦略） コードの変更は全て Git で管理し、main ブランチへの直接 push を禁止している。corporate-site では develop ブランチで作業し、main へのマージは意図的な操作が必要になる設計だ。

監査ログと承認フローの設計

Stage 3（実行権限）では、「誰が・いつ・何を・なぜ実行したか」を記録するログが重要になる。

synapse では、外部への送信操作のログを保存している。何か問題が起きたとき、いつ・何を送ったかを遡れる状態にしておくことが、信頼を維持する基本だ。

承認フローも同様だ。synapse の提案書送信スキルでは、送信前に Gmail で確認メッセージを送り、承認の返信を受け取ってから送信する設計 にしている。今後は Discord / Slack への対応も予定している。全工程を自動化するより一段遅くなるが、「最終確認は人間がする」という感覚を維持することが、経営判断としては正しいと判断した。

6 プロダクトで学んだパターンと失敗

synapse — 最初の失敗が一番の教師

synapse は最初に実装したため、最も多くの失敗を経験した。

最大の失敗は「エージェントに権限を与えすぎた」ことだ。最初の設計では、エージェントが必要だと判断した操作を全て実行できる状態にしていた。「制約は後で追加すればいい」という考えで始めたが、この考えは間違いだった。

実際に起きた問題は、エージェントが「良かれと思って」設定ファイルを書き換えたことだ。作業を依頼したところ、直接依頼した作業だけでなく、関連すると判断したファイルも変更した。その変更が他の業務に影響を与え、問題の特定に時間がかかった。

教訓: 制約は最初から書く。権限は最小から始めて、必要になった時に広げる。

この失敗以降、CLAUDE.md の書き方が変わった。「できること」ではなく「してはいけないこと」を先に書くようになった。

montage — エンジニアに依頼すべきだった部分

montage を実装する中で、「これはエンジニアに依頼すべきだった」と判断した箇所が複数あった。

具体的には、動画の品質チェックロジックだ。montage では生成した動画のテキストや映像が品質基準を満たしているかを自動チェックする仕組みがあるが、そのロジックの設計は非エンジニアには難しかった。

映像の評価基準を定義するには「フレームレートとは何か」「ビットレートが動画品質にどう影響するか」という技術知識が必要だった。Claude Code に「適切な品質チェックを実装して」と依頼すると実装はしてくれるが、その実装が本当に適切かを判断できなかった。

結果として、この部分の実装も外部エンジニアには依頼せず、Claude Code に動画ライブラリ Remotion のドキュメントを読ませながら段階的に自分で進めた。技術的判断に確証が持てない箇所では、Claude 自身に複数案を提示させて選ぶ形にし、後で動作検証で品質を担保した。

非エンジニアが Claude Code を使う限界は「何が良い設計か判断できない領域」だ。

生成されたコードが正しく動くかどうかは Claude Code が検証できる。しかし「このアーキテクチャが適切か」「この設計は将来の拡張に対応できるか」という判断は、技術的な経験が必要だ。

corporate-site — デザインと機能の境界

corporate-site の実装で最も時間がかかったのは、デザインシステムの整備だった。

Claude Code は UI コンポーネントを実装できる。ボタン、カード、レイアウトなどの部品を生成できる。しかし「これが八雲のブランドとして正しいか」の判断は、デザインの専門知識が必要だ。

解決策として、DESIGN.md（視覚言語の定義ドキュメント）を先に整備し、Claude Code に「DESIGN.md に従って実装せよ」と指示する形にした。

この方法は機能したが、限界もある。DESIGN.md に書かれていない視覚判断が必要な場面では、Claude Code は「それっぽい」デザインを生成する。「それっぽい」が「正しい」かどうかは人間が判断する必要がある。

具体的な手戻り事例として、magazine 記事の TOC が長くなりすぎてレイアウトが崩れた（fix(magazine/article): cap TOC at 50vh with internal scroll）、booking 画面の cancel ボタンが dark mode で背景に溶けて見えなくなっていた（fix(booking): make cancel button visible in dark mode）、magazine footer の Yakumo ロゴが magazine 内に表示されていたが本来は corporate site 側に表示すべきだった（fix(magazine/footer): send the yakumo logo back to the corporate site）など、視覚判断の漏れがコミット単位で残っている。

corporate-site の今回のリビルド版は約 2 週間で実装した。エンジニアに依頼した場合の正確な比較は難しいが、従来は数ヶ月単位だった工数規模を 2 週間で完遂できた感覚はある。

経営判断として何を決めるか — 導入前のチェックリスト

どの業務・担当者から始めるか

Claude Code を組織に導入する場合、最初の適用先は以下の条件を満たす業務から始めるべきだ。

始めやすい業務の特徴:

手順が定義できる（「こうすれば正解」が言語化できる）
出力の品質を自分で判断できる（何が良い出力か分かる）
失敗しても取り返しがつく（送信ボタンを押す前に確認できる）
繰り返し発生する（自動化の効果が積み上がる）

synapse での最初の適用は「提案書ドラフトの生成」だった。顧客名・要件・金額を渡すと、八雲の提案書フォーマットに沿った draft を生成する。この作業は条件を全て満たしていた。手順が定義できる、品質判断ができる、送信前に内容を確認できる、案件ごとに繰り返し発生する。

準備コストの見積もり

Claude Code の導入コストは「クロードのサブスクリプション費用」だけではない。実質的に必要な準備コストがある。

CLAUDE.md の初期設計: 数日から 1 週間程度 初期設計はエンジニアが担当した方が効率的だ。非エンジニアが一から設計すると、試行錯誤の時間が長くなる。

skill の整備: 1 スキルあたり数時間から半日程度 最初の数スキルは時間がかかる。定義の方法に慣れると、後半は速くなる。

担当者のトレーニング: 1 人あたり数日程度 「Claude Code を使う」ではなく「skill を実行する」という操作に慣れるまでの時間。

維持・更新: 月数時間程度 失敗から学んだルールの追記、skill の改善、新しい業務への適用拡大。

KPI の設定（何を成功とみなすか）

Claude Code への投資を「成功した」と言えるのはどういう状態か。

短期的な指標（3 ヶ月）:

定型業務の処理時間が 70 % 以上短縮された
担当者が「使えている」と自己評価できる

中期的な指標（6〜12 ヶ月）:

新しい業務への適用が自律的に増えている（担当者が自分で skill を追記・改善している）
重要な判断に使う時間が増えた（定型作業から解放されて）

長期的な指標（1 年以上）:

組織の「情報処理速度」が変化している
人員を増やさずに、事業規模を拡大できている

八雲での実態を正直に書くと、3 ヶ月目時点で定型業務の処理時間は目標通り短縮できた。中期・長期の指標はまだ評価途中だ。

目標 70 % 短縮 → 達成 90 % 以上

まとめ — 段階的な権限委譲ロードマップ

非エンジニアが Claude Code で実装できた範囲

6 プロダクトを実装した経験から、非エンジニアが Claude Code で「実装できた」範囲をまとめる。

実装できた:

業務フローを言語で定義し、skill として機能させること
CLAUDE.md にルールを追記し、エージェントの行動を制限すること
Stage 1（情報収集）→ Stage 2（ドラフト生成）→ Stage 3（実行）の段階的拡張
失敗から学んで制約を改善するサイクルを回すこと

実装できなかった（エンジニアが必要だった）:

技術的な品質の良し悪しを判断する設計判断
型の定義・API 設計・データ構造の設計
パフォーマンス・セキュリティに関わる実装の妥当性確認
CLAUDE.md の初期構造設計

経営判断としての投資判断

「Claude Code への投資は正しかったか」という問いに対する現時点の答えを書いておく。

正しかった。ただし、期待していた「コスト削減」よりも、「実行できることの拡張」の方が大きな価値だった。

エンジニアを雇わずにプロダクトを動かせている事実は、コスト計算だけでは説明できない。「やりたいことができる」という状態が、意思決定の速度を変えた。アイデアから実装まで、自分でサイクルを回せることが、事業の推進力を変えた。

Claude Code は「効率化ツール」ではなく「実行力の民主化」だと感じている。この表現が正確かどうか分からないが、「今まで技術的に諦めていたことが、できるようになった」という変化が、最も正直な評価だ。

次のステップとしての権限委譲ロードマップ

本記事を読んでいる経営者・事業責任者への提案として、段階的なロードマップを示す。

Week 1-2: 観察 自分が 1 週間の業務で行っている作業を書き出す。「これを繰り返している」と気づく作業をリストアップする。

Week 3-4: Stage 1 の試行 リストアップした作業の中から、「情報収集・まとめ」に当たるものを 1 つ選び、Claude Code に試させる。出力をそのまま使うのではなく、「参考として見る」段階から始める。

Month 2-3: CLAUDE.md の初期整備 試行を続けながら、「これは意図通りに動かない」と感じた点を CLAUDE.md に書き加える。エンジニアに初期設計を依頼するのが理想だが、できなければ Claude Code 自身に「このプロジェクトの CLAUDE.md を整備したい」と相談するところから始める。

Month 3-6: Stage 2 への拡張 Stage 1 が安定して動いている状態で、「ドラフト生成」に当たる作業を追加する。提案書、報告書、コンテンツ——繰り返し作っている文書から始める。

Month 6 以降: Stage 3 への判断 外部連携・自動送信の検討は、Stage 1/2 で十分な実績を積んでからにする。ここまで来ると、「どこを自動化し、どこに人間が介在するか」の感覚が磨かれているはずだ。

非エンジニアが Claude Code を使う組織設計の技術側面——CLAUDE.md の具体的な構造、skill の実装パターン、エージェント設計のアーキテクチャ——については engineering 側の記事「非エンジニアが Claude Code を使う組織設計の技術構造」で詳述している。

本記事は八雲が運用する owned media パイプラインの中で、Claude Code の支援を得て執筆されている。本記事はその経験に基づいて書かれている。

Related: AI エージェントを事業の中心に据える設計原則