社内業務を「AI駆動化」するとは

この資料の主役は「スキル」という個別の機能ではなく、社内の定型業務を Claude Code に任せていく取り組みそのものです。「なぜ今やるのか」は前のページの背景と狙いのとおり——ここからは、その話をあなたの業務の目線に引き寄せて、「どんな作業が対象になるのか」「実例では何がどこまで自動なのか」「どんな部品でできているのか」を具体化していきます。

先に、全体を1枚の絵にしておきます：

毎回くり返している「あの作業」を、Claude に任せる

職場には、手順は決まっているのに毎回それなりの時間がかかる作業がたくさんあります。背景と狙いで挙げた例を、あなたの毎日の業務の言葉に置き直すと——心当たりはないでしょうか：

• 議事録の整形：会議メモから決定事項・宿題・期日を、いつもの型に整理する
• 日報・週報：その日にやったことを、決まったフォーマットにまとめる
• 調査もの：ある企業や業界について、公開情報を調べて要点を出典付きでまとめる
• チェック・レビュー：提出物を、決まった観点（誤字・数字の整合・書き漏れ）で点検する
• 提案書・見積書づくり：調査 → 課題整理 → 文書化、という毎度おなじみの流れ

これらに共通するのは「やり方（手順）が決まっている」ことです。やり方が決まっている作業は、その手順を Claude Code に一度覚えさせておけば、次からは頼むだけで同じ品質で片づきます。これが「社内業務のAI駆動化」の基本的な発想です。人間は、最終判断や、AIが苦手な"その場の空気を読む"部分に集中できます。

逆に、次のような仕事はスキル化に向きません（少なくとも、人間の確認を厚くする前提が要ります）：

• その場の判断が仕事の本体（例：クレーム対応の方針を決める）——手順書にできる部分が少ない
• 正解が毎回変わる、根拠が社内の暗黙知にしかない——AI が調べようがなく、それらしい答えを作ってしまう
• 個人情報や未公表の財務・人事情報を入れないと成り立たない——入力内容は外部の AI サービスに送られる（下の「リスクと対策」参照）

💡 迷ったら「この手順を、新人に文書で渡して任せられるか」で判断してください。渡せるならスキル化できます。渡せないなら、まず人間がやる部分と AI に任せる部分を切り分けるところからです。

この資料が実例にするもの：提案書の自動作成

上に挙げた業務のうち、この資料が実例として通しで使うのが「お客様向け提案書の自動作成」です。社内で実際に作った proposal-automation という仕組みで、次のことが自動で行われます：

企業名を渡すだけで——その会社の経営方針・市場環境をWebで調査 → 抱えていそうな課題を分析 → 提案の切り口を洗い出し → （どの切り口で行くかは人間が選ぶ） → 見積もり・スケジュールまで含んだ提案書のドラフトを作成 → 提出前のセルフチェックまで。

この一連の流れでは、調査と執筆の大部分をAIが受け持ちます（所要時間の実測は背景と狙いのとおりです）。ただし「どの切り口で提案するか」という営業判断だけは人間が握る設計です（なぜそうしたのかは Section 3 の実話で説明します）。大事なのは、これが数ある社内業務の"一例"にすぎないこと。同じやり方で、議事録でも日報でもレビューでも自動化できます。

AI駆動化を支える「4つの部品」——この資料の地図

業務をAI駆動化するときの道具立ては、大きく4つに分かれます。この資料はこの4つを順番に扱います。

提案書の例で言えば、スキルが「経営戦略の調べ方」「見積もりの作り方」といった各作業のやり方を持ち、ワークフローがそれらを正しい順番で流し、コネクタ/MCPを足せば（この題材ではまだ使っていませんが）Web検索の代わりに社内に蓄積された情報へ直接繋ぐこともできる——という関係です。そしてナレッジが、「顧客名を公開資料に書かない」のようなどの作業でも守ってほしい前提と、過去の調査結果や議事録のような判断の元になる知識を持たせます。

💡 まずは①スキルから始めるのがおすすめです。4つの中でいちばん作るのが簡単で（テキストファイル1枚）、単体でもすぐ役に立つからです。②③は「複数のスキルを繋ぎたくなったら」「社内システムのデータを使いたくなったら」、④は「どの作業を頼むときも共通で言っている決まりごとがあるな」「資料はあるのに、聞かれるたびに探しているな」と思ったら進めば十分です。

先に要点：効果・コスト・人間の役割

細部に入る前に、判断に必要な要点だけ先にまとめます。

⚠️ 導入前に知っておくべきリスクと対策

AIの自動化には固有のリスクがあります。本資料はいずれも実話ベースで、対策とセットで各所に組み込んでいます（詳細は該当節へ）。

対策の詳しい中身は、それぞれの節で実話とセットで扱います。まずは、いちばん簡単で単体でもすぐ役に立つ部品——スキルから始めましょう。

次のページへ：Section 1　スキルを知る・使う →

Section 1：定型業務を任せる基本部品 — スキルを知る・使う

1-1. スキルとは何か

ある作業を頼むたびに、その作業のやり方を Claude Code に毎回説明していませんか。「議事録をまとめるときは、決定事項と宿題を分けて、宿題には期日を付けて…」——こうした口頭で繰り返し説明していた作業手順を、名前のついた手順書にして棚に置いておく仕組みがスキルです（作業に関係なく毎回言う決まりごとは、別の部品「ナレッジ」で扱います → 5-2節）。

• 一度スキルにすれば、/スキル名 と打つだけで呼び出せます。また、依頼の内容から Claude が「この作業はあのスキルの出番だ」と判断して自動で使ってくれることもあります
• 実体は SKILL.md というただのテキストファイル（Markdown）です。プログラミングは一切不要で、日本語で手順を書くだけです

教材フォルダの実例

教材フォルダ（提案書自動作成）には、提案書作成の工程ごとに12個のスキルが入っています。例えば：

ポイントは、どれも「人間がやるなら30分〜数時間かかる定型作業」を、手順書として言語化してあることです。スキル化の候補は「またこの作業か」と思った瞬間に見つかります。

1-2. 演習1：教材のスキルを使ってみる（教材フォルダ）

1-3. SKILL.md の解剖 — 中身はこれだけ

スキルファイルは「ヘッダー（3項目の自己紹介）＋本文（手順書）」の2部構成です。教材フォルダの skill-collect-strategy を簡略化して見てみます：

---
name: skill-collect-strategy
description: 顧客企業の経営方針・重点領域・中期目標を、IR資料や公式サイト、
  ニュースなどの公開情報から調査して箇条書きでまとめる。お客様向け提案書を
  作成する際、最初のステップとして必ず使う。
allowed-tools: WebSearch, WebFetch, Read
---

## 目的
提案書は、顧客企業の経営方針とずれていると響かない。提案の土台として、
まず顧客企業が中長期的に何を目指しているかを、公開情報から把握する。

## 手順
1. 渡された企業名で、中期経営計画・IR資料・プレスリリース等をWeb検索で探す
2. 見つかった情報から、経営方針・重点領域・中期目標を抽出する
3. 情報の鮮度（いつ時点の情報か）を必ず確認し、出力に記載する
4. 非上場企業などで公開情報が乏しい場合、無理に情報を作り出さない

## 出力フォーマット
（まとめ方の型をここに書く）

## 気をつけること
- 噂レベルの情報とIR資料のような一次情報を同列に扱わない
- 誇張・断定を避ける。分からないことは「不明」「推測」と明記する

ヘッダー（--- で挟まれた部分）に書ける項目はほかにもありますが、まずはこの3つを覚えれば十分です：

💡 本文は呼ばれた時だけ読まれる：Claude が常に読んでいるのは description だけで、本文はスキルが呼ばれた時に初めて読まれます。だから手順書が長くなっても、普段の会話の邪魔にはなりません。

1-4. スキルフォルダの構成 — 同梱できるファイルと役割

スキルは「1フォルダ＝1スキル」で、フォルダ名がそのまま呼び出しコマンド名になります（meeting-summary/ → /meeting-summary）。フォルダに必ず要るのは SKILL.md の1つだけですが、補助ファイルを同梱することもできます：

skill-name/
├── SKILL.md        ← 必須
├── reference.md    ← 参考資料（任意）
├── templates/      ← 雛形（任意）
└── scripts/        ← 実行スクリプト（任意）

各ファイルの役割と使いどき（名前は自由です。上記は分かりやすい例）：

💡 補助ファイルも会話の邪魔にならない：1-3節の「本文は呼ばれた時だけ読まれる」仕組みは補助ファイルにも効きます。読まれるのは「スキルが呼ばれ、かつ本文がそのファイルを参照したとき」だけなので、長い資料を同梱しても普段の会話には影響しません。

この教材での使い分け（設計判断の実例）

1-5. 置き場所とスコープ

スキルは、置き場所によって使える範囲が変わります：

💡 用語ミニ解説：
・~ …… 自分のユーザーフォルダ（ホーム）のこと
・「.」始まりのフォルダ（.claude 等）…… 隠しフォルダ。標準設定では画面に表示されないので、探すときは Claude に「中身を見せて」と頼むのが早道
・リポジトリ …… チームで共有しているプロジェクトの保管場所（この教材フォルダの元も proposal-automation というリポジトリです）
・コミット＆プッシュ …… 変更を記録して共有場所へ反映する操作。これも Claude に頼めます（4-1節）

この教材も後者の形で作られています。フォルダごと受け取った人は（ZIPでも、clone＝リポジトリを自分のPCへ複製する操作でも）、12個のスキルを追加設定なしでそのまま使えます——これが 4-1節 で扱う「スキル共有」の正体です。

1-6. 演習2：既存スキルの中身を見てみる（教材フォルダ）

1-7. 作る前に知っておく — 既に用意されているスキル

スキルの入手経路は自作だけではありません。①最初から入っている（組み込み）／②配布されているものを導入する（プラグイン）／③自作するの3つがあり、作り始める前に①②を確認する癖をつけると、車輪の再発明を避けられます。

組み込みスキル — Claude Code に最初から同梱されているもの

自作しなくても、Claude Code には最初から多数のスキルが入っています。代表例：

• このほかにも多数あります。利用できる顔ぶれは環境やバージョンで変わるので、「いま使えるスキルの一覧を教えて」と Claude に聞くのが確実です
• 組み込みスキルは .claude/skills/ フォルダを覗いても見えません（本体に同梱されていて、呼ばれたときに読み込まれるため）。「フォルダに無い＝使えない」ではない点に注意してください

配布されたスキルを導入する — プラグインという仕組み

スキルは「プラグイン」というパッケージの形で配布されていることもあります。2-6節のコラムで扱う skill-creator も、この形で配布されている道具の1つです。

• 入手先：Anthropic 公式の配布カタログ（マーケットプレイス）。CLI版は /plugin コマンド、デスクトップ版は入力欄の下の「＋」ボタン → プラグイン から導入します
  ▶ デスクトップ版の画面を見る（2枚）

  

  ① 入力欄の下の「＋」ボタン → プラグイン → プラグインを参照 を選ぶ（導入済みのプラグインもここに並びます）

  

  ② 開いたプラグイン一覧（公式カタログ）。「追加」を押すだけで導入できます

• 中身：1つで複数の道具を同梱できます——スキルのほか、コマンド（決まった呼び名で起動する指示）やフック（決まったタイミングで自動実行される仕掛け）など。例：「スキル作成を支援する skill-creator」「チームの規約チェック一式」「特定サービス連携」
• 注意：導入するプラグインは、提供元が信頼できるか（公式か）を確認してから入れてください

💡 プラグインが何か・基本的な入れ方は本資料（ここと Section 4）で触れますが、詳しい導入手順と公式カタログの一覧までは扱いません。社内ハンズオン資料 cc-handson/session2.html の 3-2節（導入例：security-guidance）・3-6節（公式マーケットプレイスの主要プラグイン一覧）を参照してください。

「探す→無ければ作る」の順番で

まとめると、定型作業を見つけたときの動きはこうなります：

1. まず「この作業をするスキルってもう無い？」と Claude に聞く（組み込み・導入済みの確認）
2. 配布されているプラグインに良いものがあれば導入する
3. それでもカバーされない、自分たちの業務に固有の定型作業こそ、自作スキルの出番——ここからが Section 2 です

☕ ここまでが「知る編」です。読み疲れたら、ここで一区切りして続きは別の日でも大丈夫です（ここから先は、手を動かす演習が中心になります）。

次のページへ：Section 2　スキルを作る・育てる →

Section 2：自分の業務を任せる — スキルを作る・育てる

2-1. 作り方の4つの入口

スキルの実体はテキストファイルなので、作り方は突き詰めると「誰かが書く」だけです。ただし「何を元に書くか」で4つの入口があり、状況によって使い分けます。

入口A：要件を言葉で伝えて、Claude に書かせる

作りたい手順を最初から言語化できるときの方法です。この教材の最初のスキルは、実際に次のような依頼で作られました：

• コツは「入力（何を渡すか）・出力（何がどんな形で出てくるか）・注意点」の3点をセットで伝えること。この3点が揃っていれば、Claude はかなり良い初版を書きます

入口B：実際にやった作業を、あとからスキル化する

実務ではこちらの方が自然です。要件を先に言語化できなくても、まず1回やってみればいいのです。Claude と対話しながら作業を1回やり、うまくいったら：

• 実演した手順・途中で出した修正指示・最終的な出力の形が、そのまま手順書の材料になります
• 「またこの作業か」と思った瞬間が、この入口の使いどきです

入口C：既存スキルをコピーして改変する

2個目以降のスキルはほぼこれです。構成（目的・手順・出力フォーマット・気をつけること）を流用して中身だけ差し替えるので、速くて品質も安定します：

• コピー元は手元にあるスキルに限りません。公開されているスキルや、プラグインに同梱されているスキルも、中身は同じ SKILL.md です。ただし他者が作ったスキルは、導入前に SKILL.md と（あれば）scripts/ の中身を必ず読むこと（意図しない操作や危険な指示が仕込まれていないか確認するため）

入口D：構造を理解して、自分で手直しする

「自分で書くのは Claude に頼むのと同じでは？」と思うかもしれません。半分正しいのですが、決定的な違いが1つあります。SKILL.md の構造（1-3節）を理解している人は、Claude が書いたスキルをレビューして手直しできるのです。入口A〜Cで作った初版の品質を最終的に決めるのは、この「読める・直せる」力です。2-3節でチェック観点を示します。

2-2. 演習3：作業をやってから、スキル化する（どのフォルダでも可）

8/20 営業定例MTG メモ
・新パンフレットは10月改訂で確定（担当: 田中）
・価格表の値上げ反映は保留。9月の部会で再協議
・山田 → 競合3社の価格を調査して次回共有
・佐藤 → 見積テンプレの誤字修正（8/25まで）
・佐藤 → 顧客アンケートの集計もお願いしたい
・次回アジェンダ作成は山田

9/3 企画部 週次MTG メモ
・秋のキャンペーンはSNS中心で実施に決定（担当: 高橋）
・ノベルティの再発注は保留。在庫数の確認待ち
・鈴木 → LPの文言案を作成（9/10まで）
・高橋 → 過去キャンペーンの効果データをまとめる
・田中 → 会場の空き状況を確認して次回報告

2-3. 良いスキルのチェック観点（入口Dの実践）

Claude が書いた SKILL.md を受け取ったら、次の4点をチェックします。ダメな例→良い例で見るのが早いです：

💡 理由を添えると守られやすい：AI への指示は、命令口調を強めるより「なぜそうするのか」を添える方が効きます。禁止ルールには必ず理由をセットで書いてください。

2-4. スキルを育てる — 実行→観察→ルール追記の改善ループ

スキルは一度作って終わりではありません。実際に使い、出力の問題を見つけ、その問題が二度と起きないルールを SKILL.md に追記する——このループがスキルの品質を決めます。

提案書自動作成の開発で実際に起きた失敗と、追記されたルールを3つ紹介します。すべて本当にあった話です（登場する金額は、いずれもAIが業界相場から仮置きした試算値で、実際の商談額ではありません）：

⚠️ 実話①：AI が架空の「実績」を書いた

• 起きたこと：完成した提案書に「チャネル横断のデータ活用基盤構築の実績があります」という一文が入っていた。しかし自社資料のどこにもそんな実績は書かれていない——AI が文章を整える過程で「事実を作って」しまった。顧客に出せば虚偽の実績主張になる、一番危険なミス
• 追記したルール（skill-write-proposal）：「前工程の出力や自社概要に存在しない事実（実績・数値・固有名詞）を新たに作らない。この工程の仕事は言い換え・整文までであり、事実の追加ではない」＋実際に事故が起きた旨の注意書き

⚠️ 実話②：検算できない見積もり金額が出た

• 起きたこと：提案書の見積もり表に「上限ケース 4,680万円」とあったが、同じ表に書かれた単価×人数×期間をどう組み合わせても、この金額にならなかった。しかもレビュー工程も目視チェックだけで見逃した
• 追記したルール（skill-estimate-price）：「合計行には必ず計算式（単価×人数×月数）を併記し、検算可能にする」。さらにレビュー側にも「金額表は目視ではなく必ず自分で再計算して照合する」を追加

⚠️ 実話③：施行済みの法改正を「予定」と書いた

• 起きたこと：既に施行済みの法改正を、Web記事の古い時制のまま「施行予定」と書いてしまい、その誤りが後続の分析にもそのまま伝播した
• 追記したルール（skill-analyze-market）：「法規制・制度の施行日は、必ず今日の日付と突き合わせて『施行済み』か『未施行』かを確定して書く」

このループの本質：失敗を「今回だけ手で直す」で終わらせず、失敗の実話をルールとしてスキルに刻むこと。そうすればチームの誰が使っても、同じ失敗は二度と起きません。スキルは「チームの経験が蓄積されるノート」になります。

2-5. 演習4：自分のスキルを育てる（どのフォルダでも可）

手順書：自分の業務でスキル化するとき（チェックリスト）

演習で型を体験したら、次はいよいよ自分の業務です。ここでは追加の演習の代わりに、どの業務・どの職種にも共通する手順と確認事項を1枚にまとめておきます。実際に進めるときに、上から順に確認しながら使ってください。

💡 ステップ2で「確認待ち」になっても、それは失敗ではなく正しい手順です。確認が下りるまでダミーデータでスキルを作り込んでおけば、OKが出たその日から実データで使い始められます。

2-6. コラム — skill-creator との使い分け

※ この節はコラムです。読み飛ばしても、以降の理解に影響はありません。

スキル作成を支援する Anthropic 公式プラグイン skill-creator もあります（対話形式での作成に加え、テスト・評価・性能比較まで支援）。それでも本資料が「Claude との会話だけ」で通した理由は2つあります。1つ目は、スキルの品質を最終的に決めるのが入口D（2-1節）の「読める・直せる」力で、それは skill-creator で作ったスキルの手直しにも結局必要になるから。2つ目は、会話だけの方法なら導入不要で、どの環境でも同じように使えるからです。skill-creator の真価はむしろ「作った後の品質保証」（スキルあり／なしの効果比較や、自動起動の精度チューニング）にあります。

☕ スキルを「作って・育てる」——ここまでがスキル編（Section 1・2）です。この先の Section 3（複数のスキルを繋ぐワークフロー）と Section 4（作ったスキルをチームに配る・社内システムに繋ぐ）は、一歩進んだ内容で、読み物が中心になります。

次のページへ：Section 3　ワークフローで繋ぐ →

Section 3：何工程もある仕事を丸ごと自動化する — ワークフローで繋ぐ

3-1. Workflow とは何か

スキルが「料理人1人が持つ1品のレシピ」だとすると、Workflow は「オーダーが入ってから料理が出るまでの厨房全体の段取り表」です。複数の AI 担当者（エージェント）に、どの手順書（スキル）を、どの順番で、どれを同時並行でやらせるかを決めておく仕組みです。エージェントは、冒頭の「背景と狙い」で紹介したAIエージェントと同じものです——Claude Code は普段1体に見えますが、ワークフローの中では分身を複数呼び出して同時に働かせることができ、その1体1体がスキル（手順書）を読んで作業を進めます。

• 置き場所はフォルダ内の .claude/workflows/（スキルの置き場所と同じ考え方）。中身はプログラム（JavaScript）ですが、使う側はプログラムを読む必要はありません
• 実行はチャットで頼むだけです（例は次節で説明する「第1段階」の Workflow）：

💡 fileSlug（ファイルスラッグ）は、成果物を保存するフォルダの名前になる短い文字列です（例：企業名の短縮形）。

• 実行するとバックグラウンドで複数のエージェントが動き出し、20分〜45分ほど（段階による。実測値は演習5参照）で成果物（ファイル）ができあがります。Web検索や複数のエージェントが順番に動くため時間がかかりますが、進行中も別の会話を続けられます（待っている間は他の仕事をしていてOK）

事前情報を渡したいとき — ヒアリングメモの仕組み

実行前に proposals/（企業名）/ヒアリングメモ.md というファイルを置いておくと、調査を担当するスキルたちがWeb検索の前にそれを読み、書かれている内容を一次情報として扱います。営業が実際に聞いてきた話（予算感・社内体制・経営陣の温度感など、Webには載っていない情報）を提案に反映させたいときや、公開情報が乏しい企業を扱うときに使います。

• ファイルが無ければ、従来どおりWeb検索だけで進みます（置かなくても動作は変わりません）
• メモに書かれていないことは、これまでどおり「不明」「推測」として扱われます。メモがあるからといって、それ以外まで断定されることはありません（2-4節・実話①の「存在しない事実を作らない」ルールとの共存）

⚠️ ヒアリングメモは実案件の機微情報（予算・体制・人物評など）を含み得ます。共有リポジトリにコミットしてよいか、誰が閲覧できるかは案件ごとに判断し、取り扱いには十分注意してください（社内ルールがあればそれに従う）。

スキルと Workflow の役割分担

3-2. 実例：提案書の2段階生成

教材の Workflow は、12個のスキルを次の流れで繋いでいます：

なぜ「2段階」なのか — 実話から生まれた設計

最初は1段階（企業名→提案書まで全自動）でした。ところが同じ企業に対して同じ日に2回実行したら、全く別の提案書が出てきたのです。1回目は「法改正への緊急対応」（約2ヶ月・1,200万円規模）、2回目は「内製力強化」（約6ヶ月・4,000万円規模）。どちらも間違いではなく、Web検索でたまたま見つけた情報に提案の軸が引っ張られていました（金額はいずれもAIが業界相場から仮置きした試算値です）。

そこで「切り口の候補を網羅的に並べて、選択は人間がやる」構造に変えました。ポイントは、人間の判断を一番効く場所に置いたことです：

• 完成した提案書を事後レビューして方向性を直すのは、手戻りが大きい（ほぼ作り直し）
• 着手前に「どの切り口で行くか」を判断すれば、手戻りはほぼゼロ。AI に任せる部分と人間が判断する部分の境界設計こそが、Workflow 設計の本質です

Workflow の中身（プログラムの実例）

中身のプログラムがどんなものかを見ておきます（コードは読めなくて大丈夫——気になる人だけ開いてください）：

// エージェントに「スキルを読んで、その指示に従って作業して」と頼む
const strategy = await agent(
  `.claude/skills/skill-collect-strategy/SKILL.md を読み、その指示に従って
   企業「${companyName}」の経営戦略サマリーを作成してください。`
)

// 依存関係のない作業は parallel() で同時並行に走らせる
const [valueProp, constraints] = await parallel([...])

• つまり Workflow は「各エージェントに、どのスキル（手順書）を読ませて働かせるか」を並べたものです。作業の品質はスキル側が、段取りは Workflow 側が受け持ちます
• だから Section 2 でスキルを改善すると、Workflow 全体の品質が自動的に上がります。この分業が保守を楽にします

3-3. 演習5：Workflow の成果物を読む（教材フォルダ）

3-4. Workflow のハマりどころ（実体験より）

⚠️ エージェントは「気を利かせて」情報を落とすことがある

あるエージェントが、結果の全文を返す代わりに「結果はファイルに保存しました」という要約だけを返したことがありました。後続のエージェントは返答テキストしか受け取れないため、情報が途切れかけました。対策として、後続の工程が結果テキストを受け取る全ての指示に「結果の全文をそのまま返すこと。要約だけを返すのは禁止」という一文を入れています。

⚠️ 失敗は静かに起きる

途中のエージェントが失敗しても、Workflow は気づかず走り続けることがあります（実際、企業名が渡らないまま全工程が走り、中身が空の提案書ができたことがあります）。対策は「各工程の出力が空なら、そこで止めてエラーにする」チェックを入れること。自動化は「失敗したら大きな音で止まる」ように作るのが鉄則です。

⚠️ AI の出力は毎回変わる

同じ指示でも、Web検索の結果や文章の生成は毎回変わります。これはバグではなく性質です。「毎回同じであること」に頼る設計ではなく、変わっても大丈夫な構造（人間の判断ポイントを挟む、中間成果物を保存して根拠を追跡できるようにする、自動レビューで検算する）で受け止めます。この教材の2段階方式・調査結果（中間成果物）を保存する research フォルダ・レビュー工程は、すべてこの性質への対策です。

3-5. 自分たちでワークフローを作るには

ここまで読んで「自分の業務でも複数の工程を繋ぎたい」と思ったら、ワークフローもスキルと同じく、日本語で頼んで作らせることができます。プログラム（JavaScript）は Claude が書くので、あなたが書く必要はありません。あなたが決めるのは「どの作業を・どの順番で・どこで人間が確認するか」という流れだけです。

💡 最後の一文（空なら止める）は、3-4「失敗は静かに起きる」への対策をあらかじめ組み込むおまじないです。また、登場する3つのスキルは先に Section 2 の方法で作って、単体で動くことを確かめておくのがコツです（ワークフローは"できあがったスキルを繋ぐ"のが仕事なので）。

手順はスキルに、順番はワークフローに——「直書き」しないのが原則

実は、作業の手順そのものをワークフローの中に直接書き込む（直書きする）こともできます。しかしこの教材（提案書自動作成）は、手順はすべてスキル（SKILL.md）に置き、ワークフローは「どのスキルを・どの順で呼ぶか」だけを受け持つ形で作られています。違いは保守のしやすさに出ます：

目安はシンプルです——「2回以上使う手順・育てたい手順はスキルへ。工程どうしの受け渡しだけワークフローへ」。Section 2 で身につけた改善ループがそのままワークフロー全体の品質改善になる、という 3-2節の分業は、この作り方をしたときに初めて効きます。

設計のコツ：確率的な部分と、確定的な部分を分けて繋ぐ

もう1つ、ワークフローの設計で一番効く考え方を紹介します。仕事の中身は、性質のちがう2種類に分けられます：

• 確率的な部分（AIに任せる）：調べる・考える・文章にする——LLMの応答は毎回少し変わる（3-4で見た性質）ぶん、状況に合わせた柔軟な仕事ができる
• 確定的な部分（スクリプトに任せる）：集計・変換・チェックなど、毎回必ず同じ答えになるべき処理——プログラム（スクリプト）にすれば100%同じ結果になる（1-4で見た scripts/ の出番。プログラム自体は Claude に書かせればよい）

この2種類を切り分けて設計し、ワークフローで繋ぐ——これが安定した自動化の要です。ワークフロー自体もプログラムですが役割が違います：ワークフローは工程を繋ぐ「段取り表」、スクリプトは1つの工程を確定的にこなす「道具」です。例えば見積もりなら、金額の計算はスクリプトで確定的に行い、その結果を「顧客向けの説明文」に仕立てるのはAIが担います。こうすると「計算は絶対に間違えず、文章は柔軟」という良いとこ取りになります。

⚠️ 正直な注意：ワークフローは動く部品が多いぶん、うまく動かないときの原因探しはスキルより難しくなります（3-4のハマりどころが実際に起きます）。最初は直列2〜3工程の小さな流れから始め、エラーが出たらそのメッセージを Claude に貼って相談してください。並列や条件分岐のような複雑な形は、慣れてから（またはエンジニアと一緒に）で十分です。

次のページへ：Section 4　スキルを配る・社内データに繋ぐ →

Section 4：Claude Code を拡張する — スキルを配る・社内データに繋ぐ

この章では、ここまでに作った部品を「広げる」2つの方法を扱います。1つ目はスキルの共有・配布——作ったスキルをチームや全社に配って、みんなの道具にすること。2つ目はコネクタ / MCP——Claude を社内で日々使っているツールやデータに繋ぐこと。議事録が Slack にあるなら、日報のもとが Google ドライブにあるなら、それらを人間がコピペしなくても Claude が直接読みにいけるようになります。

☕ この章は一歩進んだ内容です。スキルとワークフローだけでも社内業務のAI駆動化は十分始められます——「作ったスキルをみんなにも配りたい」「毎回どこかから情報をコピペしているな」と思ったときに読んでください。なお、この提案書自動作成の仕組み自体はまだコネクタ/MCPを使っておらず（調査はWeb検索で完結）、後半のコネクタ/MCP の部分は「次にやれる拡張」の紹介です。

4-1. スキルを共有する — チームの資産にする

スキルの実体はただのフォルダ（テキストファイル入り）なので、共有は難しくありません。規模に応じて3つの方法があります：

• ①は渡した時点のコピーなので、以後の改善は自動では届きません。育て続けるスキルは②へ——スキルの改善（2-4節のルール追記）もコミットすれば全員に行き渡り、誰かの失敗から生まれたルールが、チーム全員の再発防止になるのが共有の最大の価値です
• 個人的な作業用スキルは ~/.claude/skills/（自分専用）に置き、チームで使うものだけ共有する、という使い分けが基本です

全社に配る — プラグイン化と社内マーケットプレイス

3つ目の方法をもう少し詳しく。チームの外——部署や全社——にスキルを届けたいときの正式ルートが「プラグイン化して、社内マーケットプレイスから配る」です。例えるなら、プラグイン＝スキルを箱詰めした製品、社内マーケットプレイス＝社内専用のアプリストア（カタログ）です。

登場人物は3人。分担はこうなります：

この3人で、スキルが全社に行き渡るまでの流れを通すとこうなります：

💡 仕組みの実体（気になる人向け）：プラグインとは、スキルのフォルダに .claude-plugin/plugin.json（名前・説明・バージョンを書いたテキスト1枚）を足しただけのものです。マーケットプレイスは、プラグインの一覧表（marketplace.json）を置いた社内のGitリポジトリ——専用サーバーの構築などは不要で、カタログを置いたリポジトリが1個あれば成立します。チームへの自動配布は、プロジェクトの設定ファイル（settings.json の extraKnownMarketplaces / enabledPlugins）に管理者が書いておく仕組みです。なお、プラグインで導入したスキルはどのフォルダで作業していても使えます——特定のフォルダを開いた人だけに届く②との違いで、これが「全社配布」の正体です。

meeting-summary-plugin/          ← 外箱（フォルダ名は自由）
├── .claude-plugin/
│   └── plugin.json              ← 名札。中身は下の1行だけ
└── skills/
    └── meeting-summary/
        └── SKILL.md             ← いつものスキルをそのまま入れる（無変更）

// plugin.json（名札）の中身
{ "name": "meeting-summary", "description": "会議メモを整理するスキル", "version": "1.0.0" }

claude-plugins/                  ← 社内マーケットプレイス用リポジトリ（private可）
├── .claude-plugin/
│   └── marketplace.json         ← カタログ（プラグインの一覧表）
└── plugins/                     ← 商品置き場（フォルダ名は自由）

// marketplace.json — "cl-tools" がカタログ名になる（まだ商品ゼロの状態。owner＝作成者情報は必須）
{ "name": "cl-tools", "owner": { "name": "組織名" }, "plugins": [] }

// marketplace.json のプラグイン一覧に1行追加
{ "name": "cl-tools",
  "owner": { "name": "組織名" },
  "plugins": [
    { "name": "meeting-summary", "source": "./plugins/meeting-summary",
      "description": "会議メモを整理するスキル", "version": "1.0.0" }
  ] }

/plugin marketplace add 組織名/claude-plugins   ← カタログ登録（初回のみ）
/plugin install meeting-summary@cl-tools        ← 導入（呼び出し名は /meeting-summary:meeting-summary になる）

// .claude/settings.json に追記される内容
{ "extraKnownMarketplaces": {
    "cl-tools": { "source": { "source": "github", "repo": "組織名/claude-plugins" },
                  "autoUpdate": true } },      ← 自動更新はここで有効化
  "enabledPlugins": { "meeting-summary@cl-tools": true } }

4-2. MCP とコネクタ — 用語の整理

• MCP（エムシーピー）：Claude のようなAIを、外部のツールやデータに繋ぐための共通の規格（決まりごと）です。正式名は Model Context Protocol。「AIと外部サービスを繋ぐための共通コンセント」だと思ってください。この規格に沿って作られた"繋ぎ先"を MCPサーバー と呼びます。
• コネクタ：MCPサーバーのうち、Slack や Notion のようにあらかじめ用意されていて、選ぶだけで繋げるようにしたものです。つまりコネクタは MCPサーバーの一種——という関係です（すべてのコネクタはMCPサーバーですが、その逆は必ずしも成り立ちません）。

💡 ざっくり：「MCP＝繋ぐための共通規格」「コネクタ＝用意済みの繋ぎ先」。細かい違いより「Claude を外部に繋ぐ仕組みなんだな」が掴めれば十分です。

まぎらわしい3つ：MCP・コネクタ・プラグインの関係

よく混同されますが、「軸」が違います——MCPとコネクタは"繋ぐ"話、プラグインは"配る"話です。

MCP（繋ぐための共通規格）
  └ MCPサーバー（規格に沿った"繋ぎ先"の実装）
        └ コネクタ ＝ 選ぶだけで繋がる"用意済み"のMCPサーバー（の一部）

プラグイン（別の軸：機能をまとめて配る"箱"）
  = スキル ＋ コマンド ＋ フック ＋ MCPサーバー設定 … を同梱して配布

4-3. 繋ぎ方を知る（CLI版・デスクトップ版）

できること自体はCLI版・デスクトップ版のどちらでも同じですが、やり方が違います——CLI版はコマンド、デスクトップ版は画面（UI）や設定ファイルです。それぞれの「いちばん手軽な入口」を見ておきます。

■ デスクトップアプリの場合

Slack・Gmail・Notion などの用意済みコネクタは、入力欄の下の「＋」ボタン → コネクタ → コネクタを参照 で開く一覧から選ぶだけで追加できます（この用途ならCLIより手軽です。追加済みコネクタの管理・切断は同じメニューの「コネクタを管理」から）。一覧に無いカスタムのサーバーは設定ファイル経由での追加になります。画面の細部はバージョンで変わるので、具体的な手順は公式ドキュメントを参照してください。

① 入力欄の下の「＋」ボタン → コネクタ → コネクタを参照 を選ぶ

② 開いたコネクタの一覧。使いたいものを選んで、画面の案内どおりにログイン・承認すると繋がります

■ CLI版の場合

登録は、ターミナルで打つ1行のコマンドだけです。打つ場所は Claude Code のチャット欄ではなく、素のターミナルです（Claude Code を開いている場合は /exit で抜けるか、別のターミナルウィンドウで打ちます）。例として使うのは、ログインもアカウント登録もいらないいちばん安全な繋ぎ先——Claude Code の公式ドキュメントに繋ぐMCPサーバー（繋ぐと、Claude が公式ドキュメントを直接検索して答えられるようになります）：

claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp

この claude mcp add が「MCPサーバーを Claude Code に登録する」コマンドです。意味は次のとおり：

4-4. 演習6：MCPサーバーを繋いでみる（どのフォルダでも可）

claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp

4-5. 業務では何に繋がるのか

実務で効いてくるのは、日々使っているツールに繋いだときです。公式に例が挙がっている代表的な繋ぎ先と、繋ぐと何ができるようになるか：

これらは多くの場合、サービスに応じた認証——ブラウザでのログイン（OAuth）か、トークン（APIキー）の設定——が必要です。認証後は自分の権限の範囲でだけ Claude が触れるようになります。データベースなど個人情報に触れうる繋ぎ先は、読み取り専用の権限に絞り、抽出結果の取り扱いに注意してください。

💡 これらの繋ぎ先の追加方法（CLI版＝コマンド／デスクトップ版＝コネクタ画面や設定ファイル）は 4-3節のとおりです。使えるコネクタの顔ぶれや手順の細部はバージョンで変わるため、最新は公式ドキュメントで確認してください。

4-6. チームで共有する・安全に使う

繋ぎ先の設定も、スキルと同じ発想でチームの資産にできます。設定の実体は .mcp.json というファイル1枚——管理者がチームの共有リポジトリに置いてコミット＆プッシュすれば、それが配布です：

// .mcp.json の最小例 — 4-3で試した公式ドキュメントサーバーを、チームの標準装備にする
{ "mcpServers": {
    "claude-code-docs": { "type": "http", "url": "https://code.claude.com/docs/mcp" }
  } }

• 受け取る側（チームのメンバー）は、フォルダを開くと初回に「このサーバーに繋いでよいか」の承認を求められ、承認するだけで使えます（勝手には繋がりません）
• この「設定ファイルを置いて配る」形は、スキルのプラグイン配布（→4-1節）と同じ発想です。繋ぎ先を追加・変更してプッシュすれば、更新も同じ経路でチームに行き渡ります
• 個人だけで使う設定も選べます（自分のPCの全プロジェクト用／今のプロジェクトだけ用など、置き場所でスコープが変わります。スキルの置き場所と同じ考え方です→ 1-5節）。

⚠️ 安全上の注意（必読）

繋いだ先のデータを Claude が読める、ということは信頼できる繋ぎ先だけを入れるのが大原則です。外部の情報を読み込むサーバーには、悪意ある指示が紛れ込む「プロンプトインジェクション」（AIに不正な命令を混入させる攻撃）のリスクがあります。提供元が確かなものに限り、社外秘・個人情報を扱うときは特に慎重に。判断に迷うものは管理者／情シスに相談してください。

この題材（提案書自動化）との地続き

正直に言うと、この提案書自動作成の仕組みは、まだコネクタ/MCPを使っていません（調査はすべてWeb検索で完結しています）。ですが、もし繋げば自然な拡張が見えてきます：

• 演習で作った meeting-summary スキルは、いまは「貼り付けた会議メモ」を処理します。Slackコネクタを足せば、貼り付けずに会議チャンネルから直接読ませられます。
• 提案書の調査は、いまはWeb検索頼みです。社内ドライブのコネクタを足せば、過去の提案書や営業のヒアリング記録を直接参照して、より自社の実態に即した提案にできます。

スキル（やり方）はそのままに、情報の入口を「コピペ」から「直結」に変える——それがコネクタ/MCPの効きどころです。

次のページへ：Section 5　ナレッジ →

Section 5：Claude に前提を持たせ、知識を育てさせる — ナレッジ（CLAUDE.md と知識ベース）

ここまでの部品は、Claude ができることを増やすものでした。この章は、Claude が知っていることを増やします。渡す知識は2種類あります——どの作業でも守ってほしい前提（実体は CLAUDE.md というテキスト1枚）と、社内資料の中身（素材のフォルダを渡して、Claude 自身に Wiki として書かせ、育てる）です。

☕ この章は Section 4 とは独立しています。「毎回同じ説明を Claude にしているな」「資料はあるのに、聞かれるたびに探しているな」と思ったときに読んでください。前提の CLAUDE.md は教材フォルダで既に使われている実物で、知識ベースは教材 ZIP の knowledge-base/ でその場で一周できます。

5-1. ナレッジとは — 「言わなくても知っている」状態を作る

4つ目の部品「ナレッジ」で渡すものは2種類——どの作業でも守ってほしい前提（5-2）と、社内資料の中身（5-3〜5-6）です。手順も広い意味では知識なので、次の表ではスキルも並べて比べます。

Claude は一般的な知識は豊富ですが、あなたの会社のことは何も知りません。放っておくと2つの損が出ます——毎回同じ説明を繰り返す手間と、説明しなかった部分を勝手な前提で進められる危険です。「ナレッジを持たせる」とは、この2つを「言わなくても知っている」状態に変えることです。

知識の渡し方は5つある

実は、この資料で既に扱った部品の中にも「知識を渡す」ものが含まれています。5つを「いつ読まれるか」の順に並べると、関係が一目で分かります：

上から下へ「常に効く → 呼ばれたら効く → 外に取りに行く」と移っていきます。下の2つは既に扱ったので、この章で新しく覚えるのは CLAUDE.md と知識ベースの2つ（ルールファイルは CLAUDE.md の補足です）——どちらも実体は Markdown のファイルとフォルダで、プログラミングは要りません。

💡 Claude Code には「自動メモリ」もあります。会話の中で分かったこと（あなたの好み、直された点）を Claude が自分で書き留めて、次回以降に使う仕組みです。ただし自分のPCの中だけで、チームには共有されません。チームで共有したい前提は、人が CLAUDE.md に書きます。

5-2. CLAUDE.md — 常に効く前提を書く

実体はテキストファイル1枚で、スキルと同じく日本語で書きます。スキルとの違いは置き場所と読まれるタイミングです。スキルは頼まれたときに読まれますが、CLAUDE.md はフォルダの直下に置き、セッションを開くたびに必ず読まれます。

何を書くか — この教材の実例

この教材フォルダにも CLAUDE.md が入っています。抜粋（一部を一般化しています）：

## 運用ルール

- git のコミット・プッシュは、ユーザーから明示的な指示があるまで行わないこと。
  演習で練習ファイルを作ることがあり、自動でコミットすると共有リポジトリに混入するため。
- site/ フォルダの中身はインターネットに全世界公開される。
  顧客名・個人アカウント名・社外秘を含む内容は置かないこと。

見どころは理由まで書いてあることです。理由が分かっていれば、Claude は書かれていない状況でも判断できます（Section 2 の「理由付きでルールを追記する」と同じ発想です）。

• 検証できるくらい具体的に：❌「丁寧に書いて」→ ✅「です・ます調で、1文は60字以内」
• 200行以下を目安に。毎回読まれるので、長いほど利用枠を消費し、守られにくくなります（公式の推奨値）
• 秘密情報（APIキー・パスワード）は書かない。チームに配られるファイルだからです

---
paths:
  - "proposals/**/*.md"
---
# 提案書ファイルを扱うときの共通ルール
- 顧客の社名は正式名称（株式会社〜）で統一する
- 金額は3桁区切り・円単位で表記する（例：1,200,000円）

.claude/rules/
├── proposals.md   ← paths: proposals/**/*.md ＋ 提案書を扱うときの指示（何行でも）
├── skills.md      ← paths: .claude/skills/**  ＋ スキルを編集するときの指示
└── general.md     ← paths なし ＝ 常に読まれる汎用ルール

---
paths:
  - "proposals/**/*.md"
  - "inputs/**/*.md"
---

効いているかは、セッションで /context を実行して「Memory files」（デスクトップ版では「メモリファイル」）に CLAUDE.md が載っているかで確認できます。書き換えたら、セッションを開き直してから確認します。

💡 スキルとの使い分け：「どの作業でも守ること」は CLAUDE.md、「ある作業を頼まれたときのやり方」はスキル。CLAUDE.md に手順を詰め込むと長くなり、全体が効きにくくなります。

次の 5-3 で扱う知識ベースでも、そのフォルダ直下の CLAUDE.md が Wiki の設計図になります。書くのは「素材（raw/）は書き換えない」「各記述に出典を残す」「資料に無いことは『資料に無い』と書く」の3つが中心です。実物は演習7 の knowledge-base/CLAUDE.md で見ます。

5-3. 知識ベース — 素材を渡して、Wiki を育てさせる

前提（CLAUDE.md）は「どの作業でも守ること」を1枚に書くものでした。ここからは、社内資料の中身そのものを Claude に持たせます。ただし人間が整理して書くのではなく、素材をフォルダに入れるだけで、Claude 自身に Wiki を書かせ、育てさせる——これが知識ベースです。

📚 出どころ：この考え方は、Andrej Karpathy 氏が 2026年4月に公開した設計メモ「LLM Wiki」が元です。3層と3操作（下）はそのまま借りています。それを経営者・実務者向けに「フォルダ1個から始めて3段階で育てる」と噛み砕いたのが PLai 社の記事「Karpathy の『AI外部脳』を Claude Code で作る方法」（2026年7月）です。

PLai 社の記事は、知識ベースの育て方を3段階に分けています。バージョン1は、人が素材を集めて、人が「反映して」と頼む形（5-3・5-4）。バージョン2は、素材を集めるのを Claude に任せる形（5-5）。バージョン3は、取り込みや点検を始めるのも、時刻や出来事をきっかけに自動にする形（5-6）です。この章では、まずバージョン1を演習で一周します（バージョン2・3は解説のみ）。

3層：集めるのは人、書くのは Claude、ルールは CLAUDE.md

knowledge-base/          ← 知識ベース1つ＝フォルダ1つ
├── CLAUDE.md            ← 設計図（Wiki の書き方の決まり）。人が書く。5-2 のとおり
├── raw/                 ← 素材。人が集めて置くだけ。Claude は書き換えない
│   ├── 01_経営戦略.md
│   └── …
└── wiki/                ← Claude が書き、育てる
    ├── index.md         ← 全ページの目録（1行要約つき）
    ├── log.md           ← 何をいつ取り込んだかの記録
    ├── …（素材1本ごとの要約ページ）
    └── …（話題ごとのページ：複数の素材をまたいで1つの話題を集める。Wiki の本体）

Karpathy 氏の言い方を借りると、知識ベースの維持で面倒なのは読むことや考えることではなく、帳簿づけ（目録を更新する、関連ページを直す、記録を残す）です。そこを Claude に任せ、人は集める・聞く・確認するに回ります。

3操作：取り込む・聞く・点検する

3つの操作のうち、人間が判断するのは「聞く」の問いと「点検する」の結果への対応だけです。「聞く」でいちばん大事なのは、Wiki に無いことを推測で埋めさせないこと——「資料に無い部分は『資料に無い』と明示して」の一文を毎回付けます（CLAUDE.md にも書いておく）。

置き場所は「専用フォルダ1個」

💡 仕事のフォルダから知識ベースを使いたいときは、仕事側の CLAUDE.md に「◯◯の判断は ～/knowledge-base/営業/wiki/index.md を先に読む」と1行書けば足ります（読みに行くときは許可を求められます）。チームで共有する話は 5-6 で触れます。

⚠️ 社内の資料で使うときは：顧客の個人情報・契約書の原本・未公表の財務／人事情報は入れず、必要なら「どこにあるか」の1行だけ書きます。知識ベースは溜める仕組みなので、一度入れたものは残り続けます（Section 0 のリスク表）。また、出典を残すことと「資料に無い」と言わせることを CLAUDE.md に書いておき、ときどき点検させます。運用のコツは、上の PLai 社の記事も参考になります。

5-4. 演習7：知識ベースを作って育てる（教材フォルダの knowledge-base/ を開いて）

ここまでできたら、バージョン1は完了です。人が素材を置き、人が「反映して」と頼みました。この先のバージョン2・3は、この2つの「人がやっていたこと」を、順に Claude と仕組みに渡していく段階です。どちらも新しい部品は要らず、Section 4 のコネクタと、Claude Code の繰り返し・定期実行の機能を組み合わせるだけです。

5-5. バージョン2：素材集めを Claude に任せる

バージョン1では、人が資料をコピーして raw/ に置きました。バージョン2では、この「集める」を Claude にやらせます。使うのは Section 4 のコネクタ（MCP）です。Slack・Google ドライブ・メールなどに繋いでおけば（4-5）、Claude が自分で取りに行き、raw/ に保存できます。

⚠️ コネクタは、会社が使ってよいと許可したものだけ繋ぎます。許可が出ていなければ、この節は読むだけにしてください。Claude が自分で取りに行くぶん、どこまで読めるかは、繋いだアカウントの権限そのものになります（4-6）。

毎回このように細かく頼むのは大変なので、集め方の決まりも知識ベースの CLAUDE.md に書いておきます：

• 保存するファイル名の付け方（例：2026-10-02_slack_営業.md）
• 元の場所（投稿やファイルのリンク）を出典として必ず残す
• 個人情報を含む投稿や、社外秘の区分が付いた資料は保存しない（5-3 末尾の ⚠️）
• raw/ には新しいファイルを足すだけで、既にあるファイルは書き換えない（バージョン1と同じ）

こうしておけば、頼み方は「今週の #営業 を集めて反映して」の一言で足ります。ただし、始めるのはまだ人です。毎週月曜に誰かが頼まないと、知識ベースは止まります。そこを自動にするのが次のバージョン3です。

5-6. バージョン3：決まった時刻・出来事で自動に回す

バージョン2までは、始めるのは人でした。バージョン3では、「毎朝9時」「毎週月曜」のような時刻や、「プルリクエスト（変更を本体に取り込んでほしいという依頼）が作られた」のような出来事をきっかけに、Claude が自分で取り込みや点検を始めます。Claude Code には、そのための仕組みが3つあります。先に選び方だけ押さえます：

• 作業している間だけ繰り返したい → /loop
• 手元のフォルダを、毎朝・毎週回したい → スケジュールタスク（デスクトップ版）
• PCを閉じていても動かしたい、出来事をきっかけにしたい → ルーティン

デスクトップ版では、スケジュールタスクとルーティンを同じ画面で作ります。「Code」タブ → サイドバーの「Routines」→「New routine」と進み、「Local」を選ぶとスケジュールタスク（自分のPCで動く）、「Cloud」を選ぶとルーティン（クラウド＝Anthropic が用意したネット上のコンピューターで動く）になります。

3つとも、きっかけが来たらあらかじめ書いておいた指示を Claude が実行します。たとえば、知識ベースのフォルダで毎週月曜の朝に動かすスケジュールタスクなら、指示はこう書きます：

バージョン2の「集める」もこの指示に足せば（「先に Slack の #営業 の先週分を raw/ に集めて」）、集める・取り込む・点検するが、人が何もしなくても毎週回ります。人に残るのは、「要確認」を読んで判断することだけです。

知識ベース以外の使い道

3つの仕組みは、知識ベース専用ではありません。「決まったきっかけで、決まった指示をこなす」作業なら何にでも使えます。例を挙げます：

⚠️ 人が見ていない間に動くので

• スケジュールタスクは、作業ごとに許可の扱いを決められます。許可が要る操作に当たると、承認するまでそこで止まります。作ったら一度「Run now」で動かし、出てきた許可の内容を確かめてから「常に許可」を選んでおきます
• ルーティンは、許可を求めずに最後まで動きます。繋いだコネクタへの書き込みも確認なしで、操作はすべてあなたの名義になります。コネクタは必要なものだけ残します。また、ルーティンは現在「研究プレビュー」（試験提供。仕様が変わったり使えなくなったりすることがある）の段階で、会社の管理者が使えないように設定していることもあります
• 自動で回すほど、人は結果を見なくなります。「要確認」を誰がいつ読むかを先に決めておきます

「出来事」をきっかけにするには

時刻ではなく出来事で動かしたいときは、ルーティンの2つのきっかけを使います。1つは GitHub（プルリクエストが作られた、リリース＝新しい版が公開された など）で、対象のリポジトリに Claude の GitHub アプリを入れておく必要があります。もう1つは起動用の URL で、ルーティンごとに専用の URL があり、そこへ外の仕組みから合図を送ると動きます（このような、別のソフトから決まった形で呼び出すための窓口を API と呼びます）。「メールが届いたら」「フォームが送信されたら」のような社内の出来事は、その出来事を検知できる別の仕組みから、この URL に合図を送る形になります。

チームで一つに

知識ベースのフォルダをリポジトリで共有すれば（4-1）、部署の知識ハブになります。ルーティンはこの形と相性がよく、PCを閉じていても定期的に取り込み・点検が走ります。ただし、ルーティン自体は作った人のアカウントに属し、チームでは共有されません。担当者を1人決めて、その人のルーティンで回します。ルーティンの変更は claude/ で始まる別のブランチ（本体を変えずに変更を置いておく、作業用の写し）に入るので、Wiki に取り込むかどうかは人が判断できます。始める前に、「素材を置く人」と「Wiki を確認する人」も決めておきます。

💡 ワンポイント（上級者向け。読み飛ばして構いません）：Google Apps Script（GAS）から Claude を呼ぶ。GAS は Google のフォーム・スプレッドシート・Gmail に付いている自動化の仕組みで、「フォームが送信されたら」「毎朝」のようなきっかけを持っています。ここから Claude を呼ぶ方法は2つあります。① Claude API を直接呼ぶ——Claude Code を通さない別の使い方で、APIキー（利用者本人であることを証明する長い合言葉。漏れると他人に使われる）の発行と、使った分だけの従量課金が必要です（Claude のサブスクリプションとは別の契約）。② ルーティンの起動用の URL に合図を送る——サブスクリプションの利用枠で動きますが、上のとおり研究プレビューの段階です。どちらも合言葉（APIキーや、合図用の鍵）を扱うので、会社で使うなら承認を取ってからにします。

つまり、スキルでやり方を教え、ワークフローで段取りを組み、コネクタで社内データに繋ぎ、ナレッジで前提と知識を持たせる——4つの部品は、最後にこの知識ベースに合流し、時刻や出来事をきっかけに自分で回り始めます。まずはフォルダ1個から始めてください。

次のページへ：まとめ・参考資料 →

まとめ・参考資料

社内業務のAI駆動化とは、くり返しの定型業務を Claude Code に任せていく取り組みでした。提案書の自動作成はその一例にすぎません。取り組みを支える部品を振り返ります。

• スキル＝名前のついた手順書。実体はテキスト1枚でプログラミング不要。description（何をするか＋いつ使うか）が自動起動の鍵
• 作る前に探す → 4つの入口で作る → 育てる：組み込みや配布プラグインに無い業務固有の作業だけを自作し、「実行→観察→理由付きルールの追記」のループで育てる
• スキルは共有してチームの資産に：方法は3つ——ファイル・ZIPで渡す／リポジトリでコミット＆プッシュ（育て続けるならこれ）／プラグインで広く配布（4-1節）
• ワークフローはスキルを繋ぐ段取り表：原則は「手順はスキルに、順番はワークフローに」（3-5節）。設計の本質は「人間が判断する場所」を決めること
• コネクタ / MCP は社内システムへの通用口：情報の入口を「コピペ」から「直結」に変える。信頼できる繋ぎ先だけを入れるのが大原則
• ナレッジ＝「言わなくても知っている」状態：前提は CLAUDE.md 1枚（どの作業でも守ること。5-2節）、知識は知識ベース（集めるのは人、整理と帳簿づけは Claude。5-3節）。出典を残す・「資料に無い」と言わせる・フォルダ1個から始める。慣れたら、集めるのをコネクタに（5-5）、始めるのを時刻や出来事に任せる（5-6）

困ったときの共通対処

演習ごとの💡にも書いてありますが、つまずきの原因はだいたい次の5つに集約されます。途中のページから読んでいる人も、まずここを見てください。

用語ミニ辞典

本文の初出時に説明はしていますが、ページをまたいで探すのは手間なので一覧にしておきます。

参考資料

• Andrej Karpathy「LLM Wiki」：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f（知識ベースの設計思想の一次資料。3層・3操作はここから）
• PLai「Karpathy の『AI外部脳』を Claude Code で作る方法」：https://plai-ai.co.jp/blog/karpathy-ai-brain/（非エンジニア向けに3段階で育てる考え方。この資料のバージョン1〜3の段階分けの参考）
• 教材の元リポジトリ：proposal-automation（README に使い方・docs/判断ログ.md に仮決め・要確認事項の記録）
• 社内ハンズオン資料：cc-handson/session2.html（skill-creator を使う場合の方法・プラグインの詳しい導入・Hooks・MCP のより詳しい設定など、本資料より一歩踏み込んだ周辺機能）
• 公式ドキュメント：https://code.claude.com/docs