Claude Codeを「社長の右腕」にする100の実践――中小企業のための業務委任・自動化・権限設計

確認日：2026-09-17。本稿はClaude CodeとFable 5.1の公式情報を確認し、図解15点と、外部通信を行わないPython実行コード15点を収録しています。コードは説明用の疑似コードではなく、Python 3.10以上でローカル実行できる小さな実務補助です。

第1章　Claude Codeを「社長の右腕」として設計する

Claude Codeの価値を、コードを速く

書けることだけで測ると、その用途は開発部門に閉じてしまいます。中小企業の経営者にとって本当に大きいのは、複数の資料を読み、情報を整理し、判断材料を並べ、文書や指示書として残す一連の仕事を、ひとつの作業環境の中で連続して進められることです。経営者の一日は、意思決定だけでできているわけではありません。決定に至るまでの検索、比較、確認、下書き、修正、共有準備に多くの時間が消えています。この周辺作業をまとめて委任できれば、社長は顧客との対話、採用、事業の方向づけ、最終判断といった、本人にしかできない仕事へ時間を戻せます。

ここでいう「右腕」は、何でも勝手に決める代理社長ではありません。入力された資料と許可された道具を使い、あらかじめ決めた判断基準に沿って作業し、確認可能な成果物を返す実務担当者です。たとえば競合調査なら、「検索して感想を述べる」のではなく、対象企業、比較軸、情報の基準日、出典、事実と推測の区別をそろえた表を作り、最後に自社の打ち手を三案に整理します。商談準備なら、相手企業の公開情報、過去の接点、今回の目的を読み、仮説、質問、提案骨子、避けるべき表現まで一枚にまとめます。仕事を「会話」ではなく「完成した成果物」で依頼することが、右腕化の出発点です。

Claude Codeはファイルやツールを扱う作業環境で、Fable 5.1はそこで選択し得るモデルです。両者を同じ機能として扱わないことが重要です。Fable 5.1の100万トークンのコンテキストと最大12.8万トークンの出力はAPI上の仕様であり、無制限の文書読解、正確性、無人稼働を保証しません（Fable 5.1公式概要、Claude Code公式概要）。長時間の処理も、PC、ネットワーク、認証、利用上限、権限設定が整って初めて成立します。本稿で右腕という言葉を使うときは、常時無監督で動かすという意味ではなく、入力、処理、確認、成果物の流れを設計し、必要な場面で人が承認する仕組みを指します。

委任に向く仕事には共通点があります。材料がファイルやWebに存在する、完成形を言葉で定義できる、途中の判断に標準的な基準を置ける、結果を人が検査できる、という四点です。逆に、相手との信頼関係そのものを扱う交渉、解雇や採用の最終判断、法務・税務・労務の専門判断、資金移動、対外送信などは、人が責任を持つ工程を残します。AIに渡せる範囲を広げるほど、この境界を曖昧にしないことが重要になります。

右腕化の基本単位は「入力→処理→確認→成果物」です。入力は資料、対象期間、目的、制約。処理は検索、抽出、比較、計算、文章化。確認は出典、数字、漏れ、権限、社外送信の可否。成果物はMarkdown、CSV、Word、スライド、チェックリストなど、次の人が使える形式です。この四つを依頼文に含めるだけで、短い質問への回答から、半日分の業務委任へ変わります。

最初に試す仕事は、売上への影響が大きい一方で、誤りを発見しやすいものが適しています。たとえば「明日の商談三件の準備メモを作る」「競合五社の料金と導入支援を比較する」「先月の議事録から未完了の宿題を抽出する」です。架空の例として、従業員30人の設備会社が、社長自身で毎週二時間かけていた重点顧客の準備を委任したとします。公開情報と社内メモから初稿を作り、社長が15分で事実確認と質問の優先順位だけを直す運用にすれば、削減できたのは文章作成の時間だけではありません。「何を調べるか」を毎回考える負担も減ります。成功の尺度は、生成量ではなく、確認を含む総所要時間、修正率、見落とし件数、成果物が実務で使われた割合です。

右腕化は、仕事を一度に全部渡すこととも違います。最初は「情報を集める」「初稿を作る」「確認項目を洗い出す」の三工程を任せ、承認と実行は人が持ちます。品質が安定したら、定型の比較やファイル生成まで範囲を広げます。この順序なら、失敗したときに原因を、入力不足、指示の曖昧さ、資料の古さ、処理の誤り、確認漏れに分解できます。任せる範囲を広げる判断基準は、三回続けて同じ品質が出たか、修正箇所が予測できるか、誤りを検出する方法があるかです。成功例を見せるときも、完成品だけでなく、人がどこを確認したかを共有します。

もう一つ大切なのは、社長自身の判断を言語化することです。右腕に任せたい仕事ほど、社長の頭の中にだけある基準へ依存しています。「この顧客は売上が大きくても無理な値引きをしない」「採用は経験年数より、学習速度と顧客への姿勢を見る」「投資は一年以内の回収だけでなく、三年後の選択肢が増えるかを見る」といった基準です。過去の決定を五件ほど選び、何を重視し、何を捨てたかを書き出すと、自社固有の判断軸が見えます。AIには結論を覚えさせるより、判断軸と例外条件を渡します。同じ「見送る」でも、資金不足なのか、戦略不一致なのかで、次に集める情報が変わるからです。

最初の実装は、右腕が扱う資料の境界を作るところから始めます。次のコードは、経営、営業、経理、採用を混ぜず、入力と成果物の置き場所をそろえるための作業フォルダを作ります。実行前に作成先を確認し、既存フォルダを上書きしないことが前提です。

コード01：作業フォルダを作る

• 利用場面：案件開始時に保存場所を統一

• 前提：Python 3.10+。ローカルのみ

• 編集箇所：案件名と--root

• 実行方法：python codes/code01_workspace.py

• 期待出力：demo_output/demo_project/以下に4フォルダ

• 限界：既存ファイルは更新せず、権限設計は別途必要

"""案件用の作業フォルダ一式を安全に作る。"""
from pathlib import Path
import argparse

FOLDERS = ("01_input", "02_work", "03_review", "04_output")

def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("name", nargs="?", default="demo_project")
    parser.add_argument("--root", default="demo_output")
    args = parser.parse_args()
    safe_name = "".join(c for c in args.name if c.isalnum() or c in "-_ ").strip()
    if not safe_name:
        raise SystemExit("案件名に使える文字がありません")
    base = Path(args.root).resolve() / safe_name
    for folder in FOLDERS:
        (base / folder).mkdir(parents=True, exist_ok=True)
    readme = base / "README.txt"
    if not readme.exists():
        readme.write_text("案件: " + safe_name + "\n成果物は04_outputへ保存\n", encoding="utf-8")
    print(base)

if __name__ == "__main__":
    main()

第2章　数時間の仕事を渡す技術――完了条件から逆算する

AIへの依頼が途中で崩れるよくある理由は、指示が短いことではなく、終点が定義されていないことです。「競合を調べて」では、対象数、比較軸、情報の新しさ、成果物の長さが決まりません。「競合五社について、料金、対象顧客、主な機能、導入支援、導入事例を公式サイトから調査し、出典URL付きの比較表と、当社が取るべき施策三案をA4三枚相当でまとめる。確認できない項目は不明と書く」まで示せば、作業の終点が見えます。良い依頼は詳しい命令の羅列ではなく、検査できる完成条件を持っています。

数時間の仕事を渡すときは、まず成果物を名詞で決めます。「調査」ではなく「競合比較レポート」、「会議準備」ではなく「会議ごとの一枚メモ」、「分析」ではなく「異常値一覧と要因仮説」です。次に読ませる範囲を指定します。フォルダ、ファイル形式、対象期間、参照してよいWebサイト、除外する情報を明記します。そのうえで、判断に迷った場合の既定方針を与えます。たとえば「数字が二つの資料で異なる場合は原典を優先し、差異を注記する」「資料が見つからない場合は推測で埋めず、未確認欄に残す」「外部送信は行わず、文案の保存まで」と書きます。これにより、些細な確認待ちで止まる回数を減らせます。

長い依頼では、途中経過より検証工程が大切です。自発的な進捗報告が行われる場合でも、それを品質保証と考えてはいけません。完了前に、リンクが開くか、表の行数が合うか、数値の合計が一致するか、出典のない断定がないか、固有名詞を取り違えていないかを自己点検させます。さらに、人間側の確認項目を三つ程度に絞ります。経営判断なら「前提は正しいか」「選択肢が現実的か」「撤回条件が明確か」、営業文書なら「顧客の発言を誇張していないか」「価格と期限は正しいか」「送ってよい相手か」です。確認項目が多すぎると、委任した仕事を人が最初からやり直すことになります。

朝に三件を依頼して昼に確認する運用は有効ですが、三件すべてを同じ重要度で扱わないことが肝心です。一件は売上に近い仕事、一件は社内管理、一件は改善実験と分けます。たとえば、商談準備、月次数値の変化抽出、過去提案書からの勝ちパターン整理です。これなら短期成果と学習を同時に得られます。夜間処理も、翌朝までPCが利用可能であること、認証が切れないこと、想定外の外部操作を許可しないこと、失敗時に再開できるログを残すことが前提です。「放置」は管理を捨てる意味ではなく、事前に管理方法を組み込むことです。

作業ログは、全思考の逐語記録ではなく、監査に必要な事実を残します。使った資料、実施した処理、除外した情報、未確認事項、生成したファイル、検証結果があれば、翌週の再利用や担当者への引き継ぎが容易になります。成果物とログは分け、経営者が先に読むのは結論と判断材料です。詳細ログは、数字に疑問が出たときや、同じ作業をスキル化するときに開きます。

コード02：完了条件をチェックする

• 利用場面：納品前に必須ファイルを機械点検

• 前提：ファイル存在と非空だけを判定

• 編集箇所：DEFAULTSと--folder

• 実行方法：python codes/code02_acceptance_check.py --create-demo

• 期待出力：acceptance-result.json。不合格は終了1

• 限界：内容品質は人が確認する

"""成果物の完了条件をJSONで点検する。"""
from pathlib import Path
import argparse, json

DEFAULTS = ["proposal.md", "estimate.csv", "evidence.txt"]

def main() -> None:
    p = argparse.ArgumentParser()
    p.add_argument("--folder", default="demo_output/check_target")
    p.add_argument("--create-demo", action="store_true")
    args = p.parse_args()
    base = Path(args.folder)
    if args.create_demo:
        base.mkdir(parents=True, exist_ok=True)
        for name in DEFAULTS:
            target = base / name
            if not target.exists():
                target.write_text("demo\n", encoding="utf-8")
    result = {name: (base / name).is_file() and (base / name).stat().st_size > 0 for name in DEFAULTS}
    report = base.parent / "acceptance-result.json"
    report.parent.mkdir(parents=True, exist_ok=True)
    passed = all(result.values())
    report.open("x", encoding="utf-8").write(json.dumps({"passed": passed, "checks": result, "note": "存在と非空だけを確認し、内容品質は判定しません"}, ensure_ascii=False, indent=2))
    print(report)
    if not passed: raise SystemExit(1)

if __name__ == "__main__":
    main()

最後に、完成後の問いを一つ加えます。「この成果物の弱点を三つ挙げ、追加調査で改善できるものを示してください」。これにより、見栄えのよい完成品と、実務上の不確実性を切り分けられます。人は弱点を読んで、今すぐ意思決定できるか、追加調査が必要かを判断します。AIに任せる範囲を広げる鍵は、指示の長さではありません。完了条件、既定方針、自己検証、人の確認という四つを、毎回同じ型で渡せることです。

依頼票には、優先順位と停止条件も入れます。たとえば「公式情報が三社中二社で見つからなければ、推測を続けず未完了として報告」「個人情報を含むファイルを検出したら処理対象から外す」「予定時間を大幅に超える場合は、取得済み情報で中間成果物を保存」とします。停止は失敗ではありません。損失や誤操作を広げないための正常な動作です。また、長い仕事を一つの巨大な指示に詰め込むより、調査、構造化、執筆、検証の区切りごとにファイルを残すと、途中から再開しやすくなります。再開時には会話履歴だけに頼らず、最新の成果物、未完了リスト、次の一手を短い引継ぎファイルにまとめます。

実務で使いやすい依頼票は、目的、背景、入力場所、対象外、成果物、完了条件、既定方針、停止条件、検証、人の承認という十欄です。毎回すべてを長文で書く必要はありません。定型業務ではテンプレートを複製し、日付、対象、今回だけの注意点を変えます。初回の依頼に30分かけても、二回目以降が5分になり、確認時間まで短くなるなら投資価値があります。反対に、毎回例外だらけで検査方法もない仕事は、無理に自動化せず、資料整理や論点抽出だけを任せます。

成果物の合格基準は、正確さ、完全さ、使いやすさの三つに分けます。正確さは数字と固有名詞、完全さは必須項目の有無、使いやすさは読み手が次の行動を取れるかです。三つを一つの「良い感じ」にまとめないことで、修正指示が具体的になります。たとえば正確だが長すぎる報告書には要約だけを直させ、項目が欠けた報告書には不足資料の探索へ戻します。評価結果を数回分残すと、どの業務をスキル化すべきかも見えてきます。

依頼者側の時間も測ります。指示作成、途中確認、最終修正を合計し、従来の作業時間と比べます。生成時間だけが短くても、確認に同じ時間がかかれば委任は成立していません。反対に、初回は時間が増えても、テンプレートと検査方法が残り、二回目から大幅に短くなる業務には継続価値があります。この比較を月単位で残すと、便利さの印象ではなく、投資判断として自動化を選べます。

時間短縮に加え、抜け漏れ、修正回数、意思決定までの日数も測れば、速さだけでは見えない改善を評価できます。

第3章　導入・基本設定――最初の10項目で事故と手戻りを減らす

Claude Codeの導入は、全社プロジェクトから始める必要はありません。

01. まず経営者自身のPC一台で始めます。目的は、機能を網羅することではなく、自社の資料でどの業務なら再現性が出るかを確かめることです。入力には、機密性の低い資料と、正解を知っている既存業務を選びます。処理を見届け、出力の癖と権限確認の挙動を理解し、成果物を人が採点します。二週間で三つの成功例ができてから、幹部へ展開するほうが説明しやすくなります。

02. 作業フォルダは「経営」「営業」「経理」「採用」のように責任と資料の境界で分けます。一つの巨大なフォルダに全社資料を置くと、関係のない個人情報を読む危険と、古い資料を誤参照する危険が増えます。案件フォルダには、入力、作業中、成果物、アーカイブを設け、ファイル名に日付と版を入れます。

03. 各フォルダで初期設定を行い、CLAUDE.mdに会社概要、事業、顧客、社内用語、成果物の保存先を書きます。これは百科事典ではなく、その場所で仕事をする人への短い業務説明書です。

04. 出力ルールも固定します。「日本語、敬体、結論から」「事実、推測、提案を分ける」「重要数値に出典と基準日を付ける」など、毎回言い直す内容を集約します。

05. 冒頭には禁則を置きます。顧客情報を外部サイトへ入力しない、送信・公開・支払い・削除は事前確認、確認できない数字を作らない、といったルールです。禁止事項は抽象語で終わらせず、具体的な操作と条件を書きます。「機密に注意」より「顧客名、個人名、未公開価格を外部サービスへアップロードしない」のほうが判定できます。

06. 個人共通の設定には、役職、重視する指標、文章の好み、判断の型を置きます。Claude Codeのユーザー共通指示は、単にホーム直下へ置くのではなく、公式に案内される ~/.claude/CLAUDE.md を使います。ただし、全案件の秘密情報を共通ファイルへ集めません。案件固有の事情は案件側へ置き、共通側は「売上だけでなく粗利と回収期間を見る」「提案には撤回条件を添える」などの判断原則に絞ります（Memory公式ドキュメント）。

07. 複雑な仕事は、最初に計画を出して対象、手順、成果物を確認してから実行します。Plan modeは探索と設計に向く働き方ですが、それだけで完全な隔離環境になるわけではありません。計画段階で「過去三年分と思っていたが、実際は七年分あった」と分かれば、処理量と優先順位を修正できます（Permissions公式ドキュメント）。

08. 削除、外部送信、支払い、公開、重要データの書き換えは、確認が必要な権限にします。CLAUDE.mdの禁則は文脈として与える指示であり、実アクセスを強制的に止める権限設定そのものではありません。/permissionsなどで実際の許可を確認し、読み取り権限も仕事に必要な範囲から始めます。安全性は注意書きだけで作れません。実際の接続権限、OSの許可、外部サービス側の役割設定まで一致させます（Permissions公式ドキュメント）。

09. 案件ごとに --resume または -r で会話や作業状態を再開する習慣を持ち、別案件の文脈を混ぜません。再開時には、前回の結論、未完了事項、最新成果物を短く確認します。長い履歴があること自体より、現在の正本がどれか分かることが重要です（CLI reference）。

10. 週一回、CLAUDE.mdを見直します。追記候補は、何度も言い直した条件、実際に起きた誤解、成果物で直した表現です。ただし失敗を見つけるたびに規則を増やすと、矛盾して読みにくくなります。「提案書は短く」と「根拠を詳細に」が衝突するなら、「本文はA4三枚、根拠は別紙」と統合します。変更日と理由を残し、月一回は不要な規則を削ります。

コード03：資料目録を作る

• 利用場面：案件資料の所在と同一性を把握

• 前提：対象フォルダを用意

• 編集箇所：--inputと--output

• 実行方法：python codes/code03_inventory.py --demo

• 期待出力：material-inventory.csv

• 限界：ファイル内容の意味は判定しない

"""資料フォルダの目録CSVを作る。"""
from pathlib import Path
import argparse, csv, hashlib

def digest(path: Path) -> str:
    h = hashlib.sha256()
    with path.open("rb") as fh:
        for chunk in iter(lambda: fh.read(1024 * 1024), b""): h.update(chunk)
    return h.hexdigest()[:12]

def safe(value: str) -> str:
    return "'" + value if value.lstrip().startswith(("=", "+", "-", "@")) else value

def main() -> None:
    p = argparse.ArgumentParser()
    p.add_argument("--input", default="demo_output/materials")
    p.add_argument("--output", default="demo_output/material-inventory.csv")
    p.add_argument("--demo", action="store_true")
    args = p.parse_args()
    source = Path(args.input)
    if args.demo:
        source.mkdir(parents=True, exist_ok=True)
        for name in ("brief.txt", "numbers.csv"):
            f = source / name
            if not f.exists(): f.write_text("sample\n", encoding="utf-8")
    if not source.is_dir(): raise SystemExit(f"入力フォルダがありません: {source}")
    rows = [[safe(str(f.relative_to(source))), safe(f.suffix.lower()), f.stat().st_size, digest(f)] for f in source.rglob("*") if f.is_file()]
    out = Path(args.output); out.parent.mkdir(parents=True, exist_ok=True)
    with out.open("x", encoding="utf-8-sig", newline="") as fh:
        csv.writer(fh).writerows([["path", "type", "bytes", "sha256_12"], *rows])
    print(out)

if __name__ == "__main__": main()

この10項目の完了条件は、設定ファイルが存在することではありません。一つの実務を、指定フォルダの資料だけで処理し、禁止操作をせず、定めた形式の成果物として保存し、人が短時間で確認できることです。導入初日は環境を完璧にするより、低リスクな一業務を最後まで通して、どこで迷い、どこに確認が必要だったかを設定へ戻すほうが有効です。

なお、/initは既存のプロジェクトを分析してCLAUDE.mdの土台を作る用途であり、会社概要や社内ルールを自動的に正しく理解する機能ではありません。生成された内容は人が読み、会社固有の用語、正本の場所、禁止操作、成果物の形式を追記します（Memory公式ドキュメント）。設定の検査には、小さなテスト案件を使います。別部門のファイルを参照しないか、未確認の数字を推測で埋めないか、外部送信の直前で止まるか、指定場所へ保存するかを確認します。これを「権限テスト」「品質テスト」「保存テスト」に分け、結果を残せば、幹部へ展開するときの標準手順になります。

第4章　経営判断・情報収集――集める作業から、決められる資料へ

情報収集の成果は、情報量ではなく意思決定が進んだかで測ります。

11. 競合三社のWebを読むときは、機能一覧だけでなく、対象顧客、価格、導入負担、支援体制、実績の示し方、更新日をそろえます。入力は公式ページと自社の顧客像、処理は同じ比較軸への正規化、確認は出典と基準日、成果物は比較表と勝ち筋三案です。「競合より安くする」と短絡せず、競合が満たしていない顧客の不安や導入障壁を探します。

12. 業界ニュースの朝要約は、記事の要約だけでは経営に届きません。事実、影響を受ける自社業務、緊急度、確認すべき担当者を付けます。同じ話題の転載記事を重複排除し、一次発表へ遡ります。

13. 決算短信やIR資料は、売上や利益の増減だけでなく、事業別構成、投資、人員、解約や受注の先行指標を複数年で見ます。PDFの表やグラフから数値を抽出した場合は、ページ番号と単位を残し、転記後の合計を検算します。

14. 補助金・助成金は、対象らしいという印象で進めないことが重要です。公募要領の版、対象者、対象経費、期間、事前着手の可否、締切、加点、必要書類をチェックリスト化します。入力に自社の所在地、規模、事業計画を含め、該当、非該当、要確認を分けます。申請可否の最終確認は事務局や専門家へ回します。

15. 新規事業案には、賛成材料より先に反対意見を十個出します。顧客が払わない理由、既存事業を傷つける可能性、営業難度、運用負荷、撤退費用を挙げ、各反論に「検証方法」を付けると、単なる否定で終わりません。

16. 意思決定メモは「前提・選択肢三案・判断・撤回条件」で統一します。撤回条件には、期限と数値を入れます。「うまくいかなければやめる」ではなく、「三か月で有料商談20件、受注3件に届かなければ追加投資を停止する」です。

17. 過去の議事録を横断するときは、発言を検索するだけでなく、決定日、決定者、理由、期限、その後の変更を結びます。同名案件や古い方針を混同しないよう、現在有効な決定を明示します。

18. 経営数値は「前年比・前月比・要因仮説」の順で読みます。季節性が強い事業で前月比だけを見る、営業日数の違いを無視する、といった誤解を防ぐためです。仮説には裏づけに必要な追加データを添えます。

19. 業法・規制の改正は、公開日、施行日、経過措置、対象業務、必要な改修、責任者を一覧にします。要約だけで運用を変えず、原文と専門家の確認を通します。

20. 定期的に「社長が知らないこと」を挙げさせる場合も、刺激的な推測を求めません。売上構成の偏り、特定顧客への依存、失注理由の未記録など、手元の証拠から見える盲点と、確かめる質問を出させます。

コード04：競合CSVを比較する

• 利用場面：競合の比較軸を横並び化

• 前提：UTF-8 CSV。先頭列company

• 編集箇所：入力CSVの列

• 実行方法：python codes/code04_competitor_compare.py --demo

• 期待出力：competitor-comparison.csv

• 限界：公開情報の正確性は別途確認

"""競合CSVを読み、項目別比較表を生成する。"""
from pathlib import Path
import argparse, csv

def safe(value: str) -> str:
    return "'" + value if value.startswith(("=", "+", "-", "@")) else value

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("--input", default="demo_output/competitors.csv"); p.add_argument("--demo", action="store_true")
    args = p.parse_args(); source = Path(args.input)
    if args.demo and not source.exists():
        source.parent.mkdir(parents=True, exist_ok=True)
        source.write_text("company,price,support\nA社,30000,平日\nB社,50000,毎日\n", encoding="utf-8")
    with source.open(encoding="utf-8-sig", newline="") as fh: rows = list(csv.DictReader(fh))
    fields = list(rows[0]) if rows else []
    out = source.with_name("competitor-comparison.csv")
    with out.open("x", encoding="utf-8-sig", newline="") as fh:
        w = csv.writer(fh); w.writerow(["項目", *[safe(r.get("company", "")) for r in rows]])
        for field in fields:
            if field != "company": w.writerow([safe(field), *[safe(r.get(field, "")) for r in rows]])
    print(out)

if __name__ == "__main__": main()

架空例として、地方の法人向け研修会社が競合五社を調べたところ、内容ではなく「稟議に使える効果測定資料」の不足が共通の離脱要因だと分かったとします。ここで勝ち筋は講座数の追加ではなく、導入前後の評価票と役員向け報告書の標準装備になります。良い調査は知識を増やすだけでなく、次に変える商品、営業資料、検証指標までつながります。

経営調査では、確度の表示を共通化すると会話が速くなります。「高」は一次資料で複数確認、「中」は一次資料一件または信頼できる二次資料、「低」は状況証拠からの仮説、といった基準です。ただし確度が高くても、自社への影響判断が正しいとは限りません。事実の確度と、予測の確度を別にします。また、情報の鮮度にも期限を設けます。価格、役員、法令、助成制度は変わりやすいため、重要な判断の直前に再確認します。調査メモには「調べた日」と「次に確認する日」を入れ、過去のレポートを現在の事実として再利用しない仕組みにします。

第5章　文書・PDF・議事録――下書きを資産へ変える

文書作成は速さだけを追うと、似たような文章が増えるだけです。

21. 提案書は「表紙→現状分析→施策三案→KPI→スケジュール→概算見積」の型で骨子を先に作り、各章に必要な根拠を割り当てます。現状分析と施策がつながっているか、KPIが施策で動かせるか、見積の範囲が明確かを確認します。

22. この型をスキル化するときは、社名だけで作れる魔法を目指すのではなく、最低限必要な入力を固定します。顧客の事業、課題の原文、予算感、期限、決裁者、過去の接点が欠けていれば、不足項目を表示する設計にします。

23. 議事録は文字起こしを「要約→参加者→決定事項→アクション→フォロー」の順に整形します。発言内容と決定事項を混同せず、アクションには担当者と期限を置きます。音声認識が怪しい固有名詞は未確認として残し、録音時刻へ戻れる情報を付けます。

24. 契約書ドラフトは、自社に不利になり得る条項、曖昧な定義、責任上限、解約、更新、知的財産、秘密保持、準拠法を論点化します。AIの役割は法的結論ではなく、専門家へ渡す質問リストと比較表を作ることです。

25. 就業規則や社内規程の改定案は、現行文、新案、変更理由、影響する手続き、移行日を差分で示します。規程だけ変えて申請フォームや給与処理が古いまま、という運用断絶を避けます。

26. 稟議書と報告書を「結論一行・理由三点・次のアクション」にそろえると、読み手が判断しやすくなります。ただし重大案件では、リスク、代替案、撤回条件を別紙に残します。短さは情報を捨てることではなく、判断に必要な順へ並べることです。

27. Word、PowerPoint、Excelを直接生成する場合は、内容の正しさに加え、実際に開けるか、文字切れがないか、数式が計算されるか、印刷時に崩れないかを確認します。社内テンプレートは見本だけでなく、余白、フォント、色、見出し階層、ファイル名を指定します。

28. 既存資料のトーンを学ばせるなら、良い見本を三〜五件に絞り、残したい特徴を言語化します。「うちらしく」だけでは、古い癖や不統一まで再現します。端的、具体的、相手への敬意、過剰な断定を避ける、といった編集方針に変換します。

29. 長文メールは「相手の関心→本題→依頼→期限」に再構成します。相手の関心はお世辞ではなく、相手にとっての意味です。依頼は一通につき主目的を一つにし、返信方法を明示します。

30. 同じ内容を「小学生にも分かる版」「役員向け版」「取引先向け版」に出し分けるときは、事実を変えず、前提知識、用語、判断材料、行動の呼びかけを変えます。役員向けには投資対効果とリスク、取引先向けには影響と対応、新人向けには具体例と手順を厚くします。

コード05：議事録からTODOを抽出する

• 利用場面：担当・期限の抜けを発見

• 前提：TODO: 記法を使用

• 編集箇所：PATTERNと--input

• 実行方法：python codes/code05_minutes_todos.py --demo

• 期待出力：minutes-todos.csvと要確認列

• 限界：自然文の全タスクは拾わない

"""議事録のTODO記法を抽出する。"""
from pathlib import Path
import argparse, csv, re

PATTERN = re.compile(r"^\s*(?:[-*]\s*)?TODO[:：]\s*(.+?)(?:\s*[|｜]\s*担当[:：](.+?))?(?:\s*[|｜]\s*期限[:：](.+))?$")

def safe(value: object) -> str:
    s = str(value); return "'" + s if s.lstrip().startswith(("=", "+", "-", "@")) else s

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("--input", default="demo_output/minutes.txt"); p.add_argument("--demo", action="store_true")
    a = p.parse_args(); src = Path(a.input)
    if a.demo and not src.exists():
        src.parent.mkdir(parents=True, exist_ok=True)
        src.write_text("議題: 新提案\nTODO: 見積更新｜担当: 佐藤｜期限: 2026-09-25\n", encoding="utf-8")
    todos = []
    for no, line in enumerate(src.read_text(encoding="utf-8").splitlines(), 1):
        m = PATTERN.match(line)
        if m: todos.append([no, *(safe(x.strip()) if x else "未設定" for x in m.groups())])
    out = src.with_name("minutes-todos.csv")
    with out.open("x", encoding="utf-8-sig", newline="") as fh: csv.writer(fh).writerows([["行", "TODO", "担当", "期限", "要確認"], *[r + ["担当・期限" if "未設定" in r[2:] else ""] for r in todos]])
    print(out)

if __name__ == "__main__": main()

文書を会社の資産にするには、完成版、根拠資料、判断の履歴を結び、検索できる名前で保存します。議事録からアクションだけを別台帳へ移す、提案書の数字を見積根拠と紐づける、といった後工程まで設計します。生成した文書が一度使われて終わるのか、次回のテンプレートになるのかで、価値は大きく変わります。

文書のレビューは、誤字脱字より先に構造を見ます。結論と根拠が対応しているか、読み手が次に取る行動が一つに定まるか、数字の基準日と範囲がそろっているかを確認し、その後に表現を整えます。AIに「もっと良くして」と頼むと、文章が長くなったり、根拠のない説得表現が増えたりします。「役員が五分で投資判断できるよう、重複を削り、費用・効果・リスク・撤回条件を一ページにする」のようにレビュー目的を指定します。最終版には承認日と版番号を付け、古い版がメール添付から再利用されないようにします。

第6章　営業・顧客対応――商談の前後を一つの流れにする

営業で最も委任効果が出やすいのは、商談中の会話ではなく、その前後に散らばる準備と整理です。

31. 商談前には、企業Web、ニュース、採用情報、過去接点から一枚の準備メモを作ります。会社概要の転記ではなく、相手の変化、想定課題、確かめる質問、提案仮説、避けるべき決めつけをまとめます。公開情報からの推測は推測と表示します。

32. 商談後は文字起こしから、相手の課題、本人が使ったキーワード、合意した次のアクションを抽出します。こちらの提案を顧客の要望に見せかけないよう、発言と解釈を分けます。

33. お礼メールは一般的な礼文ではなく、商談で相手が重視した点、こちらが約束した資料、次回の期限を反映します。送信は人が宛先、固有名詞、価格、添付を確認してからです。

34. 提案の想定Q&Aは、好意的な質問だけでなく、費用、導入負担、失敗時、他社との差、契約期間、社内説明を含む20問を用意します。回答には断定できる事実、条件付き回答、持ち帰る項目を分けます。

35. 受注・失注データから勝ちパターンを探すときは、受注案件だけを見ません。業種、規模、入口、商談回数、決裁者参加、提案内容、価格、失注理由を同じ項目に整えます。記録の偏りを示し、相関を因果と断定しません。

36. 見積根拠は、単価、数量、工数、割引、外注費、粗利をスクリプト化し、条件を変えて再計算できるようにします。例外値引きには理由と承認者を残し、見積書の表示額と内部計算を照合します。

37. 顧客リストの優先順位は、企業規模だけで決めません。課題の強さ、自社との適合、接点、導入時期、意思決定の近さ、想定粗利を評価し、根拠のない項目はゼロではなく未確認にします。

38. 展示会やセミナーの名刺データは、表記を整え、会話メモと結び、フォローの温度を分類します。一括生成した文面でも、相手固有の一文と、約束した内容を確認します。大量送信を自動化する前に、対象外条件、上限件数、配信停止の扱いを決めます。

39. 価格改定の案内は「値上げ理由・影響・代替案」で構成します。原材料や人件費という自社事情だけでなく、品質や提供体制をどう維持するか、顧客の契約や請求に何が変わるかを具体化します。

40. クレーム対応は「事実確認→謝罪→原因→再発防止」で下書きしますが、調査前に原因を断定しません。謝罪すべき不便と、法的責任の認定を混同せず、重大案件は責任者と専門家へ引き上げます。

コード06：営業案件を優先順位付けする

• 利用場面：フォロー順のたたき台を作る

• 前提：金額、確度0..1、緊急度1..5

• 編集箇所：重み式と入力CSV

• 実行方法：python codes/code06_sales_priority.py --demo

• 期待出力：sales-priority.csv

• 限界：関係性や戦略的重要度は人が加味

"""営業案件を金額・確度・緊急度で優先順位付けする。"""
from pathlib import Path
import argparse, csv, math

def formula_safe(v: object) -> str:
    s = str(v); return "'" + s if s.startswith(("=", "+", "-", "@")) else s

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("--input", default="demo_output/deals.csv"); p.add_argument("--demo", action="store_true")
    a = p.parse_args(); src = Path(a.input)
    if a.demo and not src.exists():
        src.parent.mkdir(parents=True, exist_ok=True)
        src.write_text("deal,amount,probability,urgency\nA社,1200000,0.7,5\nB社,800000,0.9,3\n", encoding="utf-8")
    with src.open(encoding="utf-8-sig", newline="") as fh: rows = list(csv.DictReader(fh))
    for row in rows:
        amount, probability, urgency = float(row["amount"]), float(row["probability"]), int(row["urgency"])
        if not math.isfinite(amount) or amount < 0 or not 0 <= probability <= 1 or not 1 <= urgency <= 5:
            raise SystemExit("amount>=0、probability=0..1、urgency=1..5で指定してください")
        row["score"] = round(amount * probability * (1 + urgency / 10))
    rows.sort(key=lambda x: x["score"], reverse=True)
    out = src.with_name("sales-priority.csv")
    with out.open("x", encoding="utf-8-sig", newline="") as fh:
        w = csv.writer(fh); w.writerow(["順位", "案件", "スコア"])
        for i, row in enumerate(rows, 1): w.writerow([i, formula_safe(row["deal"]), row["score"]])
    print(out)

if __name__ == "__main__": main()

架空例として、法人向け清掃会社が50件の休眠顧客を整理した結果、価格より「担当変更後に連絡が途切れた」案件が多かったとします。この場合、優先施策は値引きキャンペーンではなく、過去の要望を添えた担当者紹介と現状確認です。AIは候補抽出と文案作成を担い、営業責任者が対象選定と送信を承認します。営業自動化の目的は接触数を増やすことではなく、顧客理解を失わずに準備時間を短くすることです。

営業成果物は、CRMへ戻せる形にします。商談メモの自由文だけで終わらせず、課題、導入時期、予算、決裁者、競合、次回日、確度、根拠発言を項目化します。空欄を推測で埋めないことも大切です。未確認項目は、次回質問へ自動的に変換します。営業会議では、担当者の印象ではなく、確度が変わった案件、期限を過ぎたアクション、同じ理由で停滞する案件を優先して見ます。これにより、AIの役割が日報の文章化から、管理者が介入すべき案件の発見へ広がります。

第7章　マーケティング・発信――量産より、一貫した検証を作る

発信では、生成量が成果に見えやすいため注意が必要です。

41. 自社サイトの文章は、ターゲット別に三案を出し、誰のどの課題に、何を、なぜ自社が提供できるかを比較します。改善案には、対象ページ、変更理由、期待する行動、測定指標を付けます。

42. ブログやメルマガの月間ネタは「テーマ×切り口」の表で作り、認知、比較、導入、継続のどの段階に向けた内容かを示します。似た記事の重複と、営業現場で頻出する質問の未掲載を確認します。

43. SNS投稿をストーリー型、ノウハウ型、実績型で作る場合も、事実の核を一つにします。実績型は顧客の許諾、数字の定義、期間を確認し、架空の成功例を実績のように書きません。

44. LPはAIDA型などの構成を使い、注意、関心、欲求、行動がつながっているかを見ます。CTAを十案作るだけでなく、資料請求、相談、見積など、訪問者の温度に合った行動を選びます。

45. セミナー資料の台本は、各スライドの目的、話す要点、具体例、次へのつなぎ、所要時間を作ります。情報量ではなく、参加者が終了後に何を判断し、何を実行できるかから逆算します。

46. 顧客インタビューから事例記事を作るときは、導入前の状況、選定理由、実施内容、変化、今後を本人の発言に沿って構成します。効果を誇張せず、顧客確認用に事実一覧を別途作ります。

47. 検索キーワード候補は、検索量だけでなく、自社が答えられる専門性、問い合わせへの近さ、既存記事との重複で評価します。同じ意図の語をまとめ、一記事一意図を基本にします。

48. プレスリリースは「見出し・リード・本文・会社概要」の型で作り、何が新しいのか、誰にどんな影響があるのか、確認可能な数字は何かを明確にします。宣伝文句をニュースの事実に置き換えます。

49. 広告文を数字、限定、問いかけなど心理的な切り口で15案作る際は、誤認を誘う限定や根拠のない最大表現を除きます。案ごとに仮説を一つに絞り、クリック率だけでなく商談化や解約まで追います。

50. 最後に、自社の哲学や価値観と照合します。価値観を美辞麗句で置くのではなく、「短期売上のために煽らない」「導入できない顧客にはそう伝える」など、文章を修正できる基準へ変えます。

コード07：発信カレンダーを作る

• 利用場面：一つの論点を複数媒体へ展開

• 前提：開始日とテーマを用意

• 編集箇所：PLANと--start

• 実行方法：python codes/code07_content_calendar.py

• 期待出力：content-calendar.csv

• 限界：各媒体の最終文面は含まない

"""1テーマを複数媒体へ展開するカレンダーを作る。"""
from pathlib import Path
from datetime import date, timedelta
import argparse, csv

PLAN = [(0, "X", "問い"), (2, "note", "解説"), (4, "LinkedIn", "事例"), (7, "メルマガ", "要約")]

def safe(s: str) -> str:
    return "'" + s if s.startswith(("=", "+", "-", "@")) else s

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("theme", nargs="?", default="AIに任せる経営実務"); p.add_argument("--start", default=str(date.today()))
    a = p.parse_args(); start = date.fromisoformat(a.start)
    out = Path("demo_output/content-calendar.csv"); out.parent.mkdir(parents=True, exist_ok=True)
    with out.open("x", encoding="utf-8-sig", newline="") as fh:
        w = csv.writer(fh); w.writerow(["公開日", "媒体", "切り口", "テーマ"])
        for days, channel, angle in PLAN: w.writerow([start + timedelta(days=days), channel, angle, safe(a.theme)])
    print(out)

if __name__ == "__main__": main()

一つのテーマを記事、メルマガ、SNSへ展開するときは、媒体ごとに同じ文章を短くするだけでは不十分です。記事は背景と根拠、メルマガは既存読者との関係、SNSは一つの気づき、営業資料は意思決定材料を担います。中心となる事実と主張を管理し、媒体別に入口と深さを変えます。成果物には公開日、対象読者、出典、承認者、再利用元を残すと、後から古い数字を使い回す事故を減らせます。

発信の評価表には、表示回数だけでなく、読了、保存、返信、資料請求、商談、受注までの流れを置きます。すべての投稿を売上へ直接結びつける必要はありませんが、各コンテンツが認知、信頼、比較、行動のどこを担うかは決めます。月末には、反応が良かった表現をそのまま量産するのではなく、読者のどの疑問に答えたから反応したのかを分析します。反応の弱い内容も、対象が違ったのか、入口が弱かったのか、提供価値自体が響かなかったのかに分ければ、次月の検証材料になります。

第8章　経理・管理業務――数字を読む時間を経営へ戻す

経理領域は効率化余地が大きい一方、誤りがそのまま支払いや申告へつながります。

51. 銀行明細CSVから勘定科目の仮仕訳を作る場合は、過去ルール、摘要、金額、取引先を使い、確信度と未分類を出します。自動確定せず、経理担当者または税理士が確認します。

52. 月次試算表からは、注目すべき変化三点を、金額、率、比較期間、要因仮説、追加確認先の順に報告します。科目名だけで判断せず、補助科目や一時要因まで見ます。

53. 資金繰り表は、入金、支払、税金、給与、借入返済を日付で並べ、入金遅延や売上減少のシナリオを試算します。残高が一定水準を下回る日と、対策の締切を示します。

54. 請求書PDFの支払予定一覧は、取引先、請求日、支払期限、金額、税区分、振込先、承認状況を抽出し、重複請求と読み取り不明を検出します。原本画像への参照を残し、一覧から直接支払う前に照合します。

55. 経費精算ルールを設定ファイルに書く場合は、上限、必要証憑、事前承認、対象外、例外承認者を構造化します。判定結果には該当規則を示し、曖昧なケースを担当者へ回します。

56. 売上、粗利、人件費の推移をグラフ化するときは、軸、単位、期間、予算線を明記し、見た目の変化を誇張しない尺度を選びます。役員会資料には、変化の説明と次のアクションを一枚に置きます。

57. 取引先ごとの与信情報は、支払遅延、取引額、公開財務、信用情報、担当者の事実メモを整理し、注意先をフラグ付けします。風評や推測を混ぜず、利用目的と閲覧範囲を制限します。

58. 固定費一覧は、契約先、月額・年額、更新日、解約条件、利用部門、利用率を並べ、「削減候補と影響」を出します。金額が小さくても管理工数が大きい契約や、解約で売上に響く契約を区別します。

59. 税理士への質問は、現状、確認したい論点、関連金額、期限、手元資料を事前整理します。「どうすればよいですか」ではなく、選択肢と自社の理解を添えると、面談時間を判断に使えます。

60. 年度予算の素案は前年実績を起点にしつつ、単純な一律増減にしません。売上の数量と単価、人件費の人数と時期、固定費の契約、投資の効果を分け、ベース、上振れ、下振れを作ります。最終的な資源配分は経営者が決めます。

コード08：月次CSVを集計する

• 利用場面：入出金明細を月・区分別に集計

• 前提：ISO日付と有限の金額

• 編集箇所：列名と--input

• 実行方法：python codes/code08_monthly_summary.py --demo

• 期待出力：monthly-summary.csv

• 限界：発生主義の利益計算ではない

"""明細CSVを月別に集計する。"""
from pathlib import Path
import argparse, csv
from collections import defaultdict
from decimal import Decimal, InvalidOperation
from datetime import date

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("--input", default="demo_output/transactions.csv"); p.add_argument("--demo", action="store_true")
    a = p.parse_args(); src = Path(a.input)
    if a.demo and not src.exists():
        src.parent.mkdir(parents=True, exist_ok=True)
        src.write_text("date,category,amount\n2026-08-01,売上,500000\n2026-08-05,経費,-120000\n2026-09-01,売上,650000\n", encoding="utf-8")
    totals = defaultdict(lambda: Decimal("0"))
    with src.open(encoding="utf-8-sig", newline="") as fh:
        for row in csv.DictReader(fh):
            try: day, amount = date.fromisoformat(row["date"]), Decimal(row["amount"])
            except (ValueError, InvalidOperation) as exc: raise SystemExit(f"日付または金額が不正です: {row}") from exc
            if not amount.is_finite(): raise SystemExit("金額は有限値で指定してください")
            totals[(day.isoformat()[:7], row["category"])] += amount
    out = src.with_name("monthly-summary.csv")
    with out.open("x", encoding="utf-8-sig", newline="") as fh:
        w = csv.writer(fh); w.writerow(["月", "区分", "合計"])
        for (month, category), amount in sorted(totals.items()):
            category = "'" + category if category.lstrip().startswith(("=", "+", "-", "@")) else category
            w.writerow([month, category, amount])
    print(out)

if __name__ == "__main__": main()

架空例として、売上3億円の制作会社が月次試算表を分析し、売上は前年並みでも外注費率が四か月連続で上昇していると判明したとします。AIが候補案件を抽出し、案件別粗利と再発注の理由を一覧にする。制作責任者が、繁忙期の一時要因か、見積不足か、内製能力の問題かを確認する。社長は、単価改定、外注先の再編、採用のどれに投資するかを決める。この分担なら、AIは会計判断を代替せず、経営判断に必要な問いを早く作れます。

経理自動化の完了条件は、数字がきれいに並ぶことではありません。元データへ戻れる、計算を再現できる、未確認箇所が見える、承認者が分かる、そして支払いや申告の前に人が確認することです。管理業務で節約した時間は、予算と実績の差を責める会議ではなく、差が生まれた仕組みを変える対話へ振り向けます。

毎月の運用では、締め日、データ取得日、担当者確認日、役員報告日を固定し、前月と同じ条件で比較できるようにします。後から修正仕訳が入った場合は、どのレポートへ影響したかを追跡します。AIが作った要因仮説は、売上台帳、案件台帳、勤怠、発注記録など、次に見るべきデータへ結びます。数字の異常を見つけたら、その場で説明を完成させようとせず、「確定した事実」「可能性の高い要因」「まだ必要な証拠」を分けます。この型があれば、経理担当者は説明を守る立場ではなく、現場と一緒に原因を確かめる役割へ移れます。

第9章　人事・採用・組織づくり──「人を見る仕事」を雑にしないために使う

人事では、採用の合否、評価、配置、処遇をAIに決めさせません。一方、判断材料、質問の抜け、記録の粒度を整える周辺作業には改善余地があります。社長や部門長が採用責任者を兼ねる中小企業で右腕を置く意味は、自動選考ではなく、人が人を見る時間を取り戻すことです。

61．求人票を「応募を集める文章」から「入社後の約束」に変える

求人票は、応募数だけを増やせば成功ではありません。実際の仕事、最初の三か月で期待する成果、向いている人と苦しくなりやすい人、評価の基準まで言語化して初めて、入社後のずれを減らせます。Claude Codeには、既存の職務記述、現場メモ、過去の求人票を読ませ、「事実」「社内で未合意の期待」「表現上の誇張」を分けさせます。そのうえで候補者向けの文章へ整えれば、社長の頭の中にしかなかった採用条件が組織の共通言語になります。給与や労働条件は必ず原本と照合し、法的な表示事項は専門家または担当者が確認します。

62．経歴書との照合は、足切りではなく面接準備に使う

履歴書や職務経歴書を機械的に点数化すると、非典型な経歴を持つ良い候補者を落としかねません。適切な使い方は、求人票の要件と経歴の対応関係を表にし、「確認できた経験」「記載だけでは判断できない点」「面接で確かめる仮説」を整理することです。たとえば「プロジェクトを主導」と書かれていても、予算、人数、本人の裁量、失敗時の対応は分かりません。Claude Codeに不明点を列挙させれば、印象に引きずられず、候補者ごとに公平な深掘りができます。個人情報を含むため、保存場所、閲覧者、保持期間を先に決めることが前提です。

63．面接質問を、候補者ごとの仮説検証に変える

「あなたの強みは何ですか」といった定番質問だけでは、実務能力も価値観も見えにくいものです。候補者の経歴と採用要件から、事実確認、行動事例、判断基準、再現性の四段階で質問案を作らせます。回答を誘導する質問や、家族・健康など職務に不要な領域へ踏み込む質問が混ざっていないかも点検します。質問案は面接官の台本ではなく、会話の質をそろえる補助線です。面接官は相手の言葉を聞き、追加質問を選び、回答の背景を理解する責任を持ちます。

コード09：面接評価票を作る

• 利用場面：事実と判断を分けて記録

• 前提：候補者名だけを引数にする

• 編集箇所：QUESTIONS

• 実行方法：python codes/code09_interview_sheet.py

• 期待出力：interview-evaluation.md

• 限界：合否判断や法的確認は行わない

"""事実欄と判断欄を分けた面接評価票を生成する。"""
from pathlib import Path
import argparse

QUESTIONS = ["具体的な成果", "困難への対応", "再現できる強み"]

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("candidate", nargs="?", default="山田 花子")
    a = p.parse_args(); name = "".join(c for c in a.candidate if c not in "\r\n")
    lines = [f"# 面接評価票: {name}", "", "判断は面接後に記入する。"]
    for i, q in enumerate(QUESTIONS, 1):
        lines += ["", f"## {i}. {q}", "- 発言・観察した事実:", "- 根拠となる具体例:", "- 評価（1〜5）:", "- 判断理由:"]
    lines += ["", "## 総合判断", "- 次の選考へ進める根拠:", "- 未確認事項:"]
    out = Path("demo_output/interview-evaluation.md"); out.parent.mkdir(parents=True, exist_ok=True)
    out.open("x", encoding="utf-8").write("\n".join(lines) + "\n")
    print(out)

if __name__ == "__main__": main()

64．1on1の記録から、次に話すべきことを準備する

1on1が近況報告だけで終わる原因の一つは、前回の約束と今回の論点がつながっていないことです。本人が共有に同意した範囲のメモから、前回の合意、未完了の支援、本人が繰り返し挙げる障害、次回確認する質問を整理させます。ただし、発言から性格や退職意向を推測させてはいけません。記録は監視の材料ではなく、上司が約束を忘れないためのものです。センシティブな相談は詳細を残しすぎず、必要なエスカレーションだけを人が判断します。

65．評価コメントのばらつきを減らす

評価制度があっても、ある上司は具体的で、別の上司は「よく頑張った」だけということが起きます。評価基準、対象期間の事実、本人の自己評価を入力し、事実と解釈を分けたコメント案を作らせると、説明の質を整えられます。禁止したいのは、記録のない印象を補って「もっともらしい人物評価」を書かせることです。Claude Codeには、根拠が足りない文へ「要確認」を付けさせ、断定を避けさせます。最終評価は責任者が行い、本人が反論や補足をできる対話をセットにします。

66．業務マニュアルを、現場の例外まで含む生きた文書にする

マニュアル作成を一度の大仕事にすると、完成時には古くなります。日々の問い合わせ、作業ログ、担当者のメモを材料に、手順、判断条件、例外、困ったときの連絡先へ再構成させます。特に価値があるのは、「AならB」と書くだけでなく、「判断できないときは止める」「この金額を超えたら承認を取る」と境界を明示できる点です。更新案は差分でレビューし、更新日と責任者を残します。自動生成した文章が実運用と一致するか、実際の担当者に手順どおり試してもらうことが欠かせません。

67．新人の30日計画を、役割ごとに個別化する

初日に資料を大量に渡し、あとは現場任せでは立ち上がりが遅れます。役割、経験、勤務形態、最初に扱う案件から、1週目の理解、2週目の練習、3週目の部分担当、4週目の自走確認へ分けた計画を作れます。各課題には「誰に聞くか」「何を提出すれば完了か」「失敗してもよい範囲」を添えます。架空の研修教材や存在しない社内制度を補完しないよう、参照可能な資料だけで作らせ、不足は不足として列挙させるのがコツです。

68．従業員アンケートを、集計して終わらせない

自由記述をテーマ別にまとめ、頻度だけでなく、影響度、緊急度、会社が直接変えられるかを整理します。少数意見でも安全やハラスメントに関わる内容は埋もれさせず、別経路で扱います。人数の少ない部署では、匿名のつもりでも文体や状況から個人が特定されることがあります。原文を広く共有せず、集約結果の閲覧範囲を限定します。そして、分析後には「すぐ変えること」「調査すること」「今は変えないことと理由」を経営側が返すところまでを一つの業務にします。

69．人事制度の改定案を、影響の比較から考える

等級、評価、報酬の制度は、一つの文言を変えるだけで採用、育成、人件費、納得感に波及します。現行規程と改定案を比較し、対象者、移行措置、例外、説明が必要な点を表にできます。さらに、若手、中堅、管理職、採用候補者という複数の立場から想定質問を出させると、経営会議前に論点が見えます。ただし、法令適合性や不利益変更の判断はAIの説明だけで進めず、社会保険労務士や弁護士など適切な専門家へ確認します。

70．経営理念を、職種ごとの日常語へ言い換える

理念が額縁の言葉になるのは、抽象度が高いからです。理念の原文は変えず、営業、開発、管理、店舗などの役割ごとに「迷ったときに何を優先するか」「してよいこと」「してはいけないこと」の例へ翻訳させます。たとえば「顧客起点」を、顧客の要求を何でも受けることと誤解しないよう、長期的な信頼や安全との関係も書きます。生成された例は正解集ではありません。現場の対話を始めるたたき台にし、実際の判断事例を追加して育てます。

共通原則は、AIに人の価値を決めさせず、判断準備と説明責任を支えさせることです。入力範囲、閲覧者、最終決定者を明示します。

第10章　自動化・スキル・フック──繰り返しを仕組みに変える

Claude Codeの価値は、繰り返す仕事を入力、処理、確認、出力に分け、再利用できる形にすることです。自動化では、機械に任せる区間と、人が確認する区間を設計します。スキルやフックはその設計を固定し、品質差を小さくします。

71．よく使う指示をコマンド化する

「先週の営業メモから未対応だけ抽出する」など、入力は変わっても手順が同じ仕事は、呼び出しやすい形にします。公式仕様ではカスタムコマンドの考え方はSkillsへ統合され、既存の.claude/commandsも引き続き動作します（Agent Skills公式ドキュメント）。名称より、対象、参照範囲、出力形式、禁止事項、完了条件を業務手順として書くことが重要です。入力が不足したら推測で埋めず、停止して不足を示す振る舞いも含めます。

72．部門の知恵をスキルとして再利用する

スキルは、「当社ではこの仕事をどう進めるか」をまとめた小さな業務パッケージです。参照資料、テンプレート、チェック項目、必要なら補助スクリプトを一緒に持たせます。営業提案なら、顧客情報の確認、課題仮説、社内事例の選定、価格表との照合、責任者レビューまでを一連にします。優れた社員の暗黙知を文章化する機会になりますが、その社員の判断を完全に複製できるわけではありません。例外処理とエスカレーション先を明示することで、模倣ではなく組織学習に変わります。

73．フックで、忘れやすい安全確認を強制する

フックは、ある動作の前後に決めた確認を走らせる仕組みです。形式チェックやログ保存を毎回実行できます。ただし、PostToolUseはツール成功後の処理であり、事後検査だけでは送信を阻止できません。さらにEdit|Writeへの一致はBashや外部編集を拾わず、ファイル変更には別の仕組みがあります（Hooks公式ドキュメント）。検査の時点と対象を確かめ、外部作用には実行前の承認を置きます。

74．朝会準備を、情報収集から論点提示まで自動化する

前日の進捗、未解決課題、今日の会議、期限の近いタスクを決められた場所から集め、朝会用の一枚にまとめます。価値は議事録の要約ではなく、「期限超過」「担当不明」「判断待ち」を目立たせることです。接続先ごとに更新時刻が違うため、資料には取得時刻を入れます。朝会で決まった内容は人が確認して正式な管理場所へ戻し、生成した一枚だけを新たな正本にしないようにします。

75．サブエージェントへ、独立した調査を分担させる

競合調査など互いに依存しない仕事は分担できます。目的、担当範囲、参照資料、禁止事項、納品形式、受入条件をbriefに書き、重複を避けます。親役は結果の矛盾、根拠、抜けを統合し、最終責任を持ちます。

76．長い処理は、中間成果を保存して再開できるようにする

長い処理では、対象一覧、処理済み・未処理・保留、生成物の場所を記録します。再開時の二重処理を防ぎ、途中結果を人が読める単位で残すことを品質基準にします。

77．申請フォームや入力様式を、業務ルールから生成する

稟議、問い合わせ、事故報告などのフォームは、項目が多すぎると使われず、少なすぎると往復が増えます。承認者が判断に必要な情報を起点に、必須項目、条件分岐、入力例、個人情報の注意を設計させます。既存の申請データから欠落が多い項目を見つけることもできます。生成後は実際の申請者と承認者の双方で試し、「入力できる」だけでなく「判断できる」フォームかを確認します。

78．週報を、出来事の羅列から経営の観測装置にする

各部署の週報形式をそろえ、成果、計画との差、障害、来週の判断依頼へ再構成します。Claude Codeには複数の報告から共通する障害や部門間の依存を抽出させ、原文への参照を付けさせます。数値は集計元と照合できる形にし、良い知らせだけを滑らかに要約してリスクが消えないようにします。経営者は短い要約から入り、気になった箇所だけ原文へ戻れます。

コード10：日次メモを週報へ集約する

• 利用場面：複数日の記録を一冊にまとめる

• 前提：日付名のtxtを用意

• 編集箇所：--input

• 実行方法：python codes/code10_weekly_report.py --demo

• 期待出力：weekly-report.md

• 限界：分類・要約はせず原文を連結

"""日次メモから週報Markdownを組み立てる。"""
from pathlib import Path
import argparse

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("--input", default="demo_output/daily_notes"); p.add_argument("--demo", action="store_true")
    a = p.parse_args(); base = Path(a.input)
    if a.demo:
        base.mkdir(parents=True, exist_ok=True)
        samples = {"2026-09-14.txt": "完了: 提案書\n課題: 数値確認", "2026-09-15.txt": "完了: 顧客面談\n次週: 見積送付"}
        for name, text in samples.items():
            f = base / name
            if not f.exists(): f.write_text(text + "\n", encoding="utf-8")
    if not base.is_dir(): raise SystemExit(f"入力フォルダがありません: {base}")
    files = sorted(base.glob("*.txt"))
    if not files: raise SystemExit("日次メモが1件もありません")
    lines = ["# 週報", "", f"対象日数: {len(files)}"]
    for f in files: lines += ["", f"## {f.stem}", f.read_text(encoding="utf-8").strip()]
    out = base.parent / "weekly-report.md"
    out.open("x", encoding="utf-8").write("\n".join(lines) + "\n")
    print(out)

if __name__ == "__main__": main()

79．失敗記録を、責任追及ではなく再発防止へ変える

障害やクレームの記録から、発生事象、影響、暫定対応、原因仮説、未確認事項、恒久対策を分離します。誰が悪いかを推測させず、観測された事実と解釈を明確に分けます。類似事故を検索し、過去の対策が実行されたかを確認する用途にも向きます。記録を罰に使う文化では入力が痩せるため、経営側が「学ぶために残す」という扱いを一貫させる必要があります。

80．自動化の最後に、人の確認点を置く

外部公開、送信、支払い、削除、契約、採用判断など、影響が大きい動作は承認待ちにします。確認画面には「何をするか」だけでなく、対象、変更前後、根拠、取り消し方法を表示します。毎回すべてを承認すると形骸化するので、低リスクな内部整形は自動、高リスクな外部作用は承認というように段階を分けます。自動化率ではなく、事故を増やさず待ち時間を減らせたかで評価します。

頻度は低くても失敗の影響が大きい仕事は、手順と確認点をスキルに残します。

第11章　MCPと外部連携──接続できることと、任せてよいことを分ける

MCPは、Claude Codeが外部のデータや機能を扱うための接続方法です。しかし、接続した瞬間にすべてのアプリを自在に使えるわけではありません。提供機能、認証権限、対象データ、各サービスの仕様に制約され、公式にも信頼できるサーバーと権限を確認する考え方が示されています（MCP公式ドキュメント）。「技術的に可能」と「会社として許可」は別です。読む、下書きする、更新する、送信するという作用の強さを分けます。

81．Gmailと予定表から、一日の準備を作る

許可されたメールと予定を参照し、会議ごとの目的、直近のやり取り、未返信、持参すべき資料をまとめます。最初は読み取り専用で始め、返信は下書きまでにします。メール送信や予定変更を許す場合も、宛先、本文、時刻を確認する承認画面を置きます。すべての受信箱を渡すのではなく、対象ラベルや期間を絞り、私的なメールや機微情報を扱わない境界を決めます。

82．Slackの会話から、決定と未決を拾う

チャットは情報量が多い一方、決定事項が流れます。指定チャンネルと期間から、決まったこと、担当、期限、保留、根拠となる投稿を抽出します。短い要約だけではニュアンスが落ちるため、元投稿へ戻れる参照を残します。全社の私的チャンネルまで横断する必要はありません。参加者が業務上想定している利用範囲と、会社の運用ルールを先に合わせます。

83．DriveやNotionを、正本を探せる知識基盤にする

似た名前の提案書や古い規程が散在すると、生成AIは誤った資料をもっともらしく再利用します。更新日、所有者、正式版かどうかを整理し、検索結果に優先順位を付けます。Claude Codeには、回答とともに参照元、更新日、矛盾する資料を示させます。外部連携の前に文書管理を整えると、AI以前の問題も改善します。権限のない文書を横断して新しい要約へ混ぜないことが重要です。

84．Zoomの記録から、次の行動へつなげる

会議の文字起こしから、決定、宿題、未解決、次回議題を抽出し、担当者に確認してから正式な議事録へ反映します。文字起こしには聞き間違いがあり、発言の皮肉や保留も落ちます。特に金額、日付、固有名詞は録画または参加者へ照合します。録画や文字起こしの取得には、参加者への告知、保存期間、閲覧権限のルールが必要です。

85．CanvaやFigmaとの連携は、量産よりブランド統制に使う

文章から複数のバナー案や図解案を作ると制作は速くなりますが、ロゴ、色、余白、禁止表現、画像権利が守られなければ公開できません。ブランドガイドと承認済みテンプレートを基準にし、AIには差し替え可能な案を作らせます。最終デザイン、アクセシビリティ、権利関係は担当者が確認します。外部ツールに渡す素材も、未発表情報や顧客情報が含まれないかを見ます。

86．e-Statなどの公的統計を、仮説の検証に使う

市場規模や地域傾向を考える際、出典不明の二次記事ではなく、公的統計の表と定義を参照します。Claude Codeには、調査年、母集団、単位、分類、欠測、比較可能性を整理させます。同じ「事業所数」でも集計対象や時点が異なれば単純比較できません。グラフを作る前に、何を示せるデータで、何は示せないかを書かせると、都合のよい物語を作りにくくなります。

87．CRMから、次に動く案件を見つける

商談の最終接触日、次回予定、フェーズ、決裁者、失注理由などを点検し、放置案件や情報欠落を洗い出します。見込み度をAIの推測だけで上書きせず、根拠となる活動履歴とセットで提示します。最初は更新候補の一覧を作るだけにし、担当者が確認後にCRMへ反映します。自動更新を許す場合も、変更対象の項目を限定し、元の値を追えるようにします。

88．会計CSVを、異常の候補を探す補助に使う

月次CSVから前年差、予算差、急増した科目、摘要の揺れを見つけ、確認すべき仕訳を並べます。これは監査や税務判断の代替ではなく、担当者が調べる順番を作る仕事です。金額の正確性、税区分、締め処理は会計システムと専門家の確認を優先します。CSVを外部サービスへ渡す場合は、口座、取引先、従業員情報などが含まれる可能性を前提に、保存先とアクセスを厳しくします。

89．接続は最小権限から始める

読み取りだけで目的を達成できるなら、書き込み権限を与えません。全件参照が不要なら、対象フォルダ、チャンネル、期間を絞ります。個人の強い権限を共有アカウントとして使わず、用途別の認証と失効手順を用意します。権限一覧は一度作って終わりではなく、担当変更、退職、連携停止のたびに見直します。便利だから広げるのではなく、具体的な業務目的が増えたときだけ追加します。

90．「何を許可したか」を台帳に残す

接続先、アカウント、権限、対象範囲、利用目的、責任者、承認日、見直し日、停止方法を一覧にします。技術担当だけが分かる状態を避け、社長や管理責任者が「今どこまで見えて、何ができるか」を理解できる表にします。不要な接続を定期的に外し、エラー時の連絡先も記載します。MCPの導入効果は接続数ではなく、安全に完了できる業務の数で測ります。

コード11：接続権限一覧を監査する

• 利用場面：MCP等の読取・書込範囲を棚卸し

• 前提：JSONにservice/read/write/owner

• 編集箇所：入力JSON

• 実行方法：python codes/code11_permission_audit.py --demo

• 期待出力：permission-audit.csv

• 限界：実システムの権限変更は行わない

"""接続先ごとの読取・書込権限一覧を監査する。"""
from pathlib import Path
import argparse, csv, json

DEMO = [{"service": "CRM", "read": True, "write": False, "owner": "営業責任者"}, {"service": "会計", "read": True, "write": True, "owner": "経理責任者"}]

def safe(value: object) -> str:
    s = str(value)
    return "'" + s if s.lstrip().startswith(("=", "+", "-", "@")) else s

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("--input", default="demo_output/permissions.json"); p.add_argument("--demo", action="store_true")
    a = p.parse_args(); src = Path(a.input)
    if a.demo and not src.exists():
        src.parent.mkdir(parents=True, exist_ok=True); src.write_text(json.dumps(DEMO, ensure_ascii=False, indent=2), encoding="utf-8")
    data = json.loads(src.read_text(encoding="utf-8"))
    out = src.with_name("permission-audit.csv")
    with out.open("x", encoding="utf-8-sig", newline="") as fh:
        w = csv.writer(fh); w.writerow(["接続先", "読取", "書込", "責任者", "要確認"])
        for x in data: w.writerow([safe(x["service"]), "可" if x["read"] else "不可", "可" if x["write"] else "不可", safe(x["owner"]), "書込権限" if x["write"] else ""])
    print(out)

if __name__ == "__main__": main()

作用最初の推奨範囲主な確認事項 読む限定した場所・期間対象外情報が混ざらないか、取得時刻は明確か 下書きする社内確認用の保存先出典、宛先、機密情報、事実誤認 更新する項目と件数を限定変更前後、戻し方、重複処理 送信・公開する原則として都度承認最終内容、相手、公開範囲、責任者

連携設計で先に作るべきものは、華やかなデモではなく権限表です。権限が説明できれば、問題が起きたときに止められます。説明できない接続は、経営の右腕ではなく、見えないリスクになります。

2026年9月の動きをどう読むか

新機能のニュースは「使える」という一語でまとめず、提供段階と対象者を見ます。CoworkとClaude chatの統合はPro／Maxへ段階展開と案内され、隔離されたコード実行と接続アプリの操作は安全境界が異なります（Cowork安全ガイド）。Google Home MCPは2026年9月16日時点で早期アクセスであり、この情報だけでは日本でのChatGPT接続条件まで確定できません（Google Home公式ヘルプ）。Agent teamsも実験機能です。経営判断では、発表の大きさより、自社アカウントで利用できるか、権限と停止方法を説明できるかを確認します。

動き提供段階の読み方導入判断 Cowork統合Pro／Maxへ段階展開対象アカウントとアプリ権限を確認 Google Home MCP9月16日時点で早期アクセス地域・接続条件を一般化しない Agent teams実験機能・標準無効本番運用の前提にしない

第12章　長時間実行とチーム設計──Fable 5.1を「任せられる右腕」にする

長く動くことと、正しく仕事を終えることは同じではありません。Fable 5.1への長時間委任では、仕事の分解、途中成果、停止条件、検証方法を設計します。

依頼を「調査」「提案」「実行」「検証」に分け、対象条件、情報源、成果物、除外条件を固定します。提案では事実、推測、経営判断を区別し、実行前に人が承認します。最後に件数、重複、出典、形式を検証します。

100件を扱うなら最初の5件で形式を確認し、25件ごとに進捗、失敗、例外を保存します。前提が違えば停止し、中間成果は人が読める場所へ残して引継ぎと再開に備えます。

コード12：実行ログと再試行を残す

• 利用場面：一時失敗と停止を区別

• 前提：ローカルの模擬処理

• 編集箇所：上限と失敗回数

• 実行方法：python codes/code12_retry_log.py

• 期待出力：retry-log.jsonl。上限到達は終了1

• 限界：待機時間や外部処理は実装していない

"""ローカル処理を再試行し、実行ログをJSON Linesへ残す。"""
from pathlib import Path
from datetime import datetime, timezone
import argparse, json, sys

def local_job(attempt: int, fail_until: int) -> str:
    if attempt <= fail_until: raise RuntimeError("デモ一時エラー")
    return "ローカル処理完了"

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("--max-attempts", type=int, default=3); p.add_argument("--fail-until", type=int, default=1)
    a = p.parse_args()
    if a.max_attempts < 1 or a.fail_until < 0: raise SystemExit("max-attempts>=1、fail-until>=0で指定してください")
    out = Path("demo_output/retry-log.jsonl"); out.parent.mkdir(parents=True, exist_ok=True)
    if out.exists(): raise SystemExit(f"上書き回避: {out}")
    for attempt in range(1, max(1, a.max_attempts) + 1):
        row = {"time": datetime.now(timezone.utc).isoformat(), "attempt": attempt}
        try:
            row.update(status="success", result=local_job(attempt, a.fail_until))
        except RuntimeError as exc: row.update(status="retry" if attempt < a.max_attempts else "stopped", error=str(exc))
        with out.open("a", encoding="utf-8") as fh: fh.write(json.dumps(row, ensure_ascii=False) + "\n")
        if row["status"] == "success": break
    print(out)
    if row["status"] != "success": sys.exit(1)

if __name__ == "__main__": main()

サブエージェントは、顧客の声、競合機能、過去提案の棚卸しなど独立作業に向きます。同じデータの書き換えや、前工程に依存する仕事は衝突が増えます。親役が範囲と形式をそろえ、矛盾を解消します。

Claude CodeのAgent teamsは通常のsubagentとは別の実験機能で、標準では無効です（Agent teams公式ドキュメント）。導入時は利用環境を確認し、実験機能を本番業務の前提にしません。使えない場合でも、仕事を分け、成果をファイルで渡し、親役が統合する設計はそのまま使えます。

Fable 5.1では、以前の版より進捗更新が少なく見える場合があり、APIではdisplay:updatesがベータ設定として案内されています（Fable 5.1公式情報）。したがって「必ず細かく報告する」と想定せず、ファイルへのチェックポイント保存を依頼側の完了条件にします。プロンプトキャッシュも長時間なら自動的に安くなる仕組みではなく、一致するprefixやTTLなどの条件があります（Prompt caching公式ドキュメント）。費用は実行ログで測ります。

短い整形や定型チェックと、複数資料の矛盾整理や経営案の比較では、必要なモデルが違います。速度、費用、品質を実測し、段階ごとに選びます。モデル名だけで品質を保証せず、同じ受入条件で比べます。

仕事の性質向く進め方人の関与 短い定型整形単発実行、軽量なモデル抜き取り確認 独立した複数調査サブエージェントで並列範囲指定と統合レビュー 大量資料の連続処理長時間実行＋チェックポイント初期5件、例外、最終検証 外部更新を伴う処理提案と実行を分離実行直前の承認 経営判断の比較複数案と反証を生成決定と説明責任

一時的な通信失敗と、入力不備、権限不足、仕様矛盾を分けます。再試行には上限を置き、入力、時刻、結果、エラーを記録します。完了条件にはファイルの存在だけでなく、件数や必須項目を含めます。

長時間委任は、止まるべきときに止まり、再開でき、根拠を人が確認できるかで評価します。

第13章　リスク・事故・権限制御──速くする前に、止められる会社にする

AIの事故は、研究・評価環境の事例と一般利用での発生頻度を分けて考えます。OpenAIが報告した6件は訓練・評価環境で観測されたもので、一般利用での発生率を示す数字ではありません（Model Misalignment Reporting Framework）。別の報告には社内専用の研究モデルが未知の脆弱性を連鎖させて制限を回避した事例もあります（Hugging Face incident and the road ahead）。過小評価も一般化もしないために、経営者は自社の情報、権限、承認、ログで影響を限定します。

同じ研究報告でいうagent spamには、公開Wikiを掲示板のように使った例も含まれます。メールの大量送信だけに狭めず、外部サービスへの不適切な書き込みとして捉える必要があります（Hugging Face incident and misalignment）。

Fable 5.1のcontent provenanceも、承認印ではありません。テキストには統計的ウォーターマーク、対象メディアにはFiles APIで取得する際のC2PAが案内されていますが、内容の正確性や社内承認を証明するものではありません（Fable 5.1公式情報）。公開前の事実確認と承認は別に残します。

91．個人情報は、入れる前に利用目的と保存先を決める

氏名、連絡先、経歴、健康、評価、顧客対応履歴などは、業務上必要だからと無制限に渡してよい情報ではありません。誰の情報を、何の目的で、どの範囲まで使い、どこへ保存し、いつ消すかを決めます。可能なら匿名化、仮名化、集計化し、原文を使わずに目的を達成します。利用する製品や契約のデータ取扱条件も確認し、現場が個人アカウントへ貼り付ける運用を放置しません。

92．確認済みと未確認を、出力の中で分ける

AIの文章は、確認済みの事実と推測が同じ調子で並ぶことがあります。出力形式に「参照元で確認」「入力から推定」「情報不足」「担当者判断」を設けます。未確認の数字や固有名詞には印を付け、外部へ出す前に原典へ戻します。文章の自然さを品質と誤認せず、重要な主張ほど根拠を近くに置きます。確認できない場合は、空欄や保留を許すことが安全性につながります。

93．法律、税務、医療などは専門家の入口として使う

論点整理、必要資料の一覧、専門家へ聞く質問の下書きには役立ちますが、個別事情を踏まえた最終判断は適切な資格者へつなぎます。「一般的には」という回答を自社の結論へ飛躍させないことです。専門家へ渡す際は、AIが作った要約だけでなく原資料も用意し、どこが未確認かを示します。相談時間を短くする補助として使うと、速度と慎重さを両立できます。

94．出典を、飾りではなく検証経路として残す

URLを並べるだけでは検証できません。どの主張がどの資料のどの部分に基づくか、発行主体、公開日、更新日、取得日を記録します。二次記事が一次資料を引用しているなら、可能な限り一次資料へ戻ります。リンク切れを想定し、許される範囲で文書名や該当箇所も残します。社内文書なら版と所有者を示します。出典のない断定は、文章から外すか、仮説として明記します。

95．最初は幹部と小さく導入する

全社一斉配布より、業務とリスクを理解する少人数で三つほどの用途を試します。たとえば会議準備、社内文書の初稿、週報整理です。入力禁止情報、外部送信の承認、問題時の連絡先を共有し、毎週の振り返りでルールを更新します。成功例だけでなく、使えなかった例、時間が増えた例も記録します。幹部が自分で触ることで、現場へ無理な「AI利用件数」を課しにくくなります。

96．社長が実際の画面を共有し、判断過程を見せる

社長自身がClaude Codeを使う画面を幹部や社員と共有し、何を依頼し、どの出力を疑い、どこで人の確認を入れたかを見せます。完成品だけを示すより、便利さと限界を同時に伝えられます。画面共有の前には顧客名、個人情報、認証情報、別案件の履歴を閉じ、練習用データを使います。経営者向けの管理画面では、生成件数より承認待ち、失敗、期限超過、権限エラーを目立たせ、止める判断へすぐ到達できる形にします。

97．部門ごとに、扱える情報と動作を決める

営業、人事、経理、広報では、扱うデータと事故の形が違います。共通の原則に加えて、部門別に入力可能な情報、利用可能な接続、外部送信の承認者、保存期間を決めます。ルールは「AIに機密を入れない」といった抽象語だけにせず、実際の文書名や例で示します。判断に迷ったときの相談先も書き、現場が隠れて使う原因になる過度な禁止を避けます。

98．成功事例を、プロンプトではなく業務設計ごと共有する

良い出力だけを共有すると、別の人が同じ結果を再現できません。入力資料、前提、指示、確認項目、人が直した箇所、所要時間、使えなかった条件まで残します。プロンプトはその一部です。特定の担当者だけが使える裏技にせず、テンプレートとチェックリストへ落とし込みます。個人情報や顧客情報は事例から除き、架空または匿名化したサンプルに置き換えます。

99．効果は「速かった気がする」ではなく実測する

導入前の所要時間、待ち時間、手戻り、エラー、外注費を少数の業務で測り、導入後と比較します。AIの実行時間だけでなく、入力準備、確認、修正、教育、運用の時間も含めます。品質は文字数や生成件数ではなく、承認一回で通った割合、誤り、問い合わせ再発率など業務に合う指標を置きます。数件の改善を全社効果に拡大して断定せず、試算は仮定を明示します。

100．空いた時間を、社長にしかできない仕事へ戻す

最後の活用法は、新しい自動化ではありません。Claude Codeが生んだ時間を、顧客との対話、幹部育成、採用の最終判断、資本配分、撤退判断、理念の更新へ戻すことです。空いた時間にさらに報告資料を増やせば、会社は忙しいままです。経営者は「何をAIへ渡すか」と同時に、「取り戻した時間で何をするか」を宣言します。右腕を持つ目的は、社長が不要になることではなく、社長が責任を持つべき仕事へ集中することです。

コード13：承認待ち下書きを作る

• 利用場面：外部作用の前に確認事項を残す

• 前提：操作内容と理由を入力

• 編集箇所：actionと--reason

• 実行方法：python codes/code13_approval_draft.py

• 期待出力：approval-pending.json

• 限界：承認済みと判定せず、実行もしない

"""実行せず、承認待ち下書きだけを生成する。"""
from pathlib import Path
from datetime import datetime
import argparse, json

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("action", nargs="?", default="顧客へ提案書を送信"); p.add_argument("--reason", default="商談後のフォロー")
    a = p.parse_args()
    draft = {
        "status": "approval_pending",
        "action_draft": a.action.replace("\n", " "),
        "reason": a.reason.replace("\n", " "),
        "created_at": datetime.now().isoformat(timespec="seconds"),
        "executed": False,
        "review_items": ["対象", "内容", "送信先", "取消可能性"],
        "note": "これは保留用下書きです。承認判定も実行も行いません。"
    }
    out = Path("demo_output/approval-pending.json"); out.parent.mkdir(parents=True, exist_ok=True)
    out.open("x", encoding="utf-8").write(json.dumps(draft, ensure_ascii=False, indent=2))
    print(out)

if __name__ == "__main__": main()

権限制御は、失敗時の影響を限定し、誰が何をしたかを追い、必要なら止めて戻す経営管理です。個別の挙動や頻度は一次資料と利用条件で判断し、未確認の話を恐怖の材料にしません。

第14章　コストと効果測定──「人件費削減」だけで判断しない

費用対効果は、月額料金と削減時間だけでは測れません。入力、確認、権限管理、失敗から戻す時間も費用です。一方、対応漏れの防止、意思決定の短縮、属人業務の可視化も効果です。まず対象業務ごとに現在の流れを測ります。

測定単位は、一つの成果が完了するまでにします。提案書なら初稿生成ではなく、顧客へ出せる版の承認までです。導入前に作業、待ち、手戻り、関与人数、外注費、重大な誤りを2〜4週間記録し、同じ定義で導入後を測ります。

コード14：実測ROIを計算する

• 利用場面：導入前後の総時間から効果試算

• 前提：after_minは準備・確認・修正込み。runs>=0

• 編集箇所：費用と入力CSV

• 実行方法：python codes/code14_roi.py --demo

• 期待出力：roi-result.json

• 限界：品質・機会損失は金額化しない

"""実測時間と費用からROIを計算する。"""
from pathlib import Path
import argparse, csv, json, math

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("--input", default="demo_output/roi-samples.csv"); p.add_argument("--demo", action="store_true")
    a = p.parse_args(); src = Path(a.input)
    if a.demo and not src.exists():
        src.parent.mkdir(parents=True, exist_ok=True)
        src.write_text("task,before_min,after_min,runs,hourly_yen\n週報,120,35,4,6000\n資料整理,90,25,8,5000\n", encoding="utf-8")
    saved_yen = 0.0
    with src.open(encoding="utf-8-sig", newline="") as fh:
        for r in csv.DictReader(fh):
            before, after, runs, rate = float(r["before_min"]), float(r["after_min"]), int(r["runs"]), float(r["hourly_yen"])
            if not all(math.isfinite(x) for x in (before, after, rate)) or min(before, after, runs, rate) < 0:
                raise SystemExit("時間・回数・単価は0以上の有限値で指定してください")
            saved_yen += (before - after) / 60 * runs * rate
    tool_cost = 30000.0; roi = (saved_yen - tool_cost) / tool_cost * 100
    report = {"monthly_saved_yen": round(saved_yen), "monthly_cost_yen": round(tool_cost), "roi_percent": round(roi, 1)}
    out = src.with_name("roi-result.json"); out.open("x", encoding="utf-8").write(json.dumps(report, ensure_ascii=False, indent=2))
    print(out)

if __name__ == "__main__": main()

たとえば、ある会社で週報集約に毎週4時間、月次提案の初稿に月12時間かかっていたとします。Claude Code導入後、週報は入力確認を含め2時間、提案初稿はレビューを含め7時間になったと仮定します。月4週なら削減は13時間です。担当者の社内原価を1時間5,000円と仮置きすれば、表面上の効果は月6万5,000円です。ただし、月額利用料、運用担当の月3時間、初期整備費を差し引く必要があります。これは説明用の架空試算であり、実際の単価と時間で置き換えます。

ROIは次のように分解すると議論しやすくなります。

区分測る項目見落としやすい点 直接費用利用料、接続費、初期設定、教育管理者とレビュー担当の時間 時間効果作業、待ち、検索、転記の短縮出力修正と再実行の時間 品質効果誤り、手戻り、期限超過、再問い合わせ問題が表面化したことで一時的に件数が増える場合 売上効果対応速度、提案数、商談化、継続率AI以外の施策との切り分け リスク効果確認漏れ、権限過多、監査対応時間事故が少ないため金額換算しにくい

処理時間が半分でも修正率が倍なら、成功とは言えません。時間が減らなくても、社長しかできなかった準備を部門長が回せれば価値があります。「速度」「品質」「自律性」「リスク」の四面で見て、部門ごとに主指標一つ、副指標二つ程度に絞ります。

検証には作業ログや成果物の履歴を使いますが、監視に変えないよう目的を説明します。AI利用回数を人事評価へ直結させると、不要な利用が増え、事故が隠れます。評価するのは業務の成果です。

三か月ごとに継続、改善、停止を判断します。効果と安全性が確認できれば継続、入力や承認が重ければ改善、目的が曖昧、修正が多い、既存ツールで十分なら停止です。使わない仕事を早く見つけ、重要な用途へ予算を寄せます。

経営会議では、「何時間使ったか」より「どの業務の完了時間がどう変わり、品質とリスクはどうなったか」を報告します。これにより、AI投資が流行への参加ではなく、改善投資として扱えるようになります。

第15章　30日導入ロードマップ──社長の右腕を、会社の習慣にする

30日で目指すのは、主対象に選んだ一つの業務を、安全に繰り返せる状態へ定着させることです。最初に候補を三つ出して比較しますが、同時には進めません。他の二つは余力があるときの観察対象に留め、主対象の入力、確認、停止、効果測定を完成させます。

1〜3日は、社長が「取り戻したい時間」から候補を三つ挙げ、主対象を一つ選びます。会議準備、既存資料の整理、社内文書の初稿などから、頻度、確認しやすさ、機密性、失敗時の影響で比べます。選定した日から、誰が何を見て、完成まで何分かかるかの現状計測も始めます。

4〜7日は、主対象の完成条件と境界を定義します。入力してよい情報、参照場所、成果物、確認者、外部送信の扱いを決めます。接続は読み取り専用、対象限定から始め、事故時の連絡先と停止方法も確認します。

8〜14日は、過去データや低リスクな実案件で小さく試します。最初の数件は責任者が全文確認し、誤り、不足、余計な作業を記録します。指示だけを保存せず、入力資料、完了条件、確認手順を含む再利用可能な形へ整えます。外部へ作用する操作は下書きまでにします。

15〜21日は、失敗例を基に手順と停止条件を改善します。入力不足、根拠不明、対象外の情報、権限不足、想定時間超過をどう検知し、どこで人へ戻すかを決めます。再試行で解決する失敗と、直ちに止める失敗を分け、権限台帳と実行ログが残ることも確認します。

22〜27日は、担当者二名が同じ手順を実行し、同程度の成果を再現できるか確認します。同時に、導入前と同じ定義で時間、手戻り、失敗件数、修正時間、品質を測ります。担当者ごとの差が大きければ、個人のセンスに頼っている箇所を手順へ戻します。

28〜30日は、実測結果から継続、改善、停止を決めます。継続する場合は責任者、正本の保存先、定期的な見直し日を置きます。残り二候補への展開は、主対象が安定し、便益と安全性を説明できてから判断します。

コード15：30日チェックリストを作る

• 利用場面：一業務の導入を段階管理

• 前提：責任者名を指定

• 編集箇所：PHASESと--owner

• 実行方法：python codes/code15_roadmap.py

• 期待出力：30day-checklist.md

• 限界：日程は組織事情に合わせて調整

"""30日導入ロードマップのチェックリストを生成する。"""
from pathlib import Path
import argparse

PHASES = [(1, 3, "対象業務を1つ選び、現状時間を測る"), (4, 7, "入力・成果物・承認者を定義する"), (8, 14, "小さな実データで試行する"), (15, 21, "失敗条件と停止条件を追加する"), (22, 27, "チーム2名で再現テストする"), (28, 30, "ROIを計測し次の業務を決める")]

def main() -> None:
    p = argparse.ArgumentParser(); p.add_argument("--owner", default="導入責任者")
    a = p.parse_args(); owner = a.owner.replace("\n", " ")
    lines = ["# 30日導入チェックリスト", "", f"責任者: {owner}", ""]
    for start, end, task in PHASES:
        lines += [f"## Day {start}–{end}", f"- [ ] {task}", "- [ ] 証拠ファイルを保存", "- [ ] 次工程へ進む条件を確認", ""]
    lines += ["## 完了条件", "- [ ] 1業務で再現可能", "- [ ] 承認箇所が明確", "- [ ] 実測ROIを記録"]
    out = Path("demo_output/30day-checklist.md"); out.parent.mkdir(parents=True, exist_ok=True)
    out.open("x", encoding="utf-8").write("\n".join(lines) + "\n")
    print(out)

if __name__ == "__main__": main()

期間経営者の判断成果物 1〜3日候補3件から主対象1件を選び、現状計測を始める候補比較、主対象、基準値 4〜7日完成条件と情報・権限の境界を決める業務定義、権限表、停止手順 8〜14日主対象を小さく試す初版手順、成果物、失敗記録 15〜21日失敗と停止条件を改善する改訂手順、例外条件、実行ログ 22〜27日担当2名で再現性と効果を測る再現確認、導入前後の実測 28〜30日継続・改善・停止を決める運用責任者、保存先、見直し日

30日後は、「時間は戻ったか」「品質は下がっていないか」「権限とデータの所在を説明できるか」「現場が問題を報告できるか」を確認します。答えられなければ、利用を広げる前に設計を直します。

今日から試す三つの依頼文

次の三つから、今日、頻度、確認しやすさ、機密性、失敗時の影響を比べて主対象を一つだけ選びます。明日は過去の案件か低リスクな実案件で試します。依頼前に個人情報や別案件の混入を確認し、実行後は事実、数字、固有名詞、未確認欄を責任者が確認します。

候補1　明日の商談準備

候補2　議事録から未完了事項を抽出

候補3　週次経営レビュー

一つを選んだら、準備、AI処理、人の確認・修正の時間と誤りを記録します。同じ条件で数回試してから30日計画へ載せ、他の二つは主対象が安定するまで保留します。

Claude Codeには調査、整理、下書き、比較、検証を任せ、社長は目的、優先順位、例外、最終責任を引き受けます。100の活用法は会社の仕事を見直す100の入口です。何を人に残し、取り戻した時間をどこへ投じるかを決めることは、最後まで社長の仕事です。

参考にした一次資料

確認日：2026-09-17。以下は記事内の製品仕様・安全上の記述を確認した一次資料です。

• Claude Codeの位置付け — ファイル・コマンド・ツールを扱う製品。モデルそのものと区別

• Fable 5.1の掲載 — 2026-09-01の発表掲載を確認。長時間の知識労働向けという製品説明と個別業務の成功保証を区別

• 文脈・出力 — API仕様1M/128K。画面側の無制限利用を意味しない

• 進捗、effort、来歴 — APIの進捗表示設定、ベータ条件を区別。来歴は正確性・社内承認の証明ではない

• キャッシュ — 一致する前方部分や保持期限など条件あり。長時間なら自動的に安いとはしない

• CLAUDE.md — ユーザー共通は ~/.claude/CLAUDE.md。指示は強制的なアクセス制御ではない

• 権限 — 実際の操作制御と自然言語の指示を区別

• 再開 — --resume/-rを確認。外部状態も復元されるとの主張はしない

• スキル — 既存カスタムコマンドとの統合。手順再利用の説明に留める

• フック — PostToolUseは成功したツール後。Edit/Writeだけでは外部編集等を拾わない。送信後の検査は送信阻止に使えない

• MCP — 接続先実装・認証・権限を要する。全サービス接続可能とはしない

• サブエージェント — 独立した文脈を持つ補助作業と、共有案件の統合責任を区別

• Agent teams — 実験機能・既定無効。復帰や調整等に制約

• Cowork統合と安全 — チャットとの統合はPro/Maxへ段階展開。隔離コード実行と接続アプリ操作を区別

• Home MCP — 2026-09-16の早期アクセス。日本のChatGPT接続条件は今回の資料だけで確定しない

• Agent spam — 公開Wikiの掲示板化等。メール大量送信だけを意味しない

• Hugging Face事故 — 主に社内専用研究モデル。未知の脆弱性を連鎖した制約回避。一般利用の発生頻度と混同しない

• 6件の開示 — 訓練・評価中の事例。無断キー利用、引用用無断アップロードなどを確認

鈴木章裕／株式会社コミクス 代表取締役
あわせて読みたい

AIの賢さは、フォルダで決まる。──毎回ゼロから説明する社長と、一度だけ書いて任せる社長

https://note.com/comix_ceo162230/n/nd8231d4c0098

AIは「やっておいて」では動かない。人も同じだった。

https://note.com/comix_ceo162230/n/n1f776c33a824

AIを使う人を増やす。その先に、仕事の型を残す

https://note.com/comix_ceo162230/n/n1603ee91beba