中小企業経営者のためのCodex実践100選――仕事を任せ、確かめ、仕組みにする15章

2026年9月18日 11:51

AIに仕事を任せたい。けれど、何から始め、どこまで任せ、何をもって「使えた」と判断すればよいのか。中小企業の現場では、この三つを決める時間こそ足りない。

本記事は、提供資料『中小企業経営者のためのCodexベストプラクティス100選』の100項目を、15章の実践記事へ再編集したものだ。導入する仕事の選び方から、営業、集計、社内ツール、手順の再利用、権限管理、30日間の定着までをつなぐ。本文中の001〜100は原資料の項目番号に対応する。

各章には図解と実行コードを一つずつ添えた。コードはPython 3.10以降と標準ライブラリで試せる小さな実例で、AIへの指示文とは区別している。UTF-8で指定のファイル名に保存し、Pythonを利用できる環境のターミナルで実行する。環境によってはpythonをpython3やpyへ読み替える。コードを読むのが難しければ、まず図解と説明を担当者と一緒に読み、入力と期待結果を確かめればよい。

企業名、会話、件数、時間、費用は説明用の架空例であり、実在企業の導入実績ではない。100項目は公式認定リストでも効果保証でもなく、中小企業向けの運用提案だ。公式機能の説明は出典を示し、利用画面・契約・管理者設定・接続状況による違いを踏まえて読む。すべてを一度に導入せず、今週繰り返す一仕事から始めよう。

第1章　最初の一仕事を選び、成果を測れる形にする

「何でもできそう」から離れ、狙いを一つにする

架空の従業員35人の設備会社「青葉設備」では、社長が生成AIの活用を呼びかけたものの、現場から出た案は議事録、見積もり、採用、問い合わせ対応とばらばらだった。ここで「営業を改善する」と掲げても、良くなったかは判定できない。最初にすべきことは、成果を「商談準備の所要時間を減らす」のように一つへ絞ることだ（001）。成果物を一枚の商談前メモと定めれば、所要時間、修正回数、利用回数を同じ仕事で比較できる。

候補を探すには、社長や担当者の一週間を、調査、集計、転記、判断、対話に分けて棚卸しする（002）。頻度と所要時間だけでなく、正誤を人がその場で確かめられるか、判断を誤った場合の影響が大きいかも記録する。青葉設備では問い合わせ転記が週8回、商談準備が週5回だった。一方、請求承認は時間がかかっても経営判断を伴う。そこで最初の候補からは外した。便利そうかではなく、繰り返しが多く、確認しやすく、判断リスクの低い

次のコードは候補を機械的に決めるものではなく、選定会議のたたき台を作る例だ。頻度などの配点は各社の事情に合わせる。

実行コード01｜業務候補の比較

from dataclasses import dataclass


@dataclass
class Task:
    name: str
    frequency: int
    minutes: int
    easy_to_check: int
    decision_risk: int


def score(task: Task) -> int:
    """高頻度・長時間・確認容易で、判断リスクが低い仕事を上位にする。"""
    return (
        task.frequency * 2
        + min(task.minutes // 10, 6)
        + task.easy_to_check * 3
        - task.decision_risk * 4
    )


tasks = [
    Task("商談前メモ", 5, 35, 3, 1),
    Task("月次請求の承認", 1, 50, 2, 3),
    Task("問い合わせ転記", 8, 20, 3, 0),
]

ranked = sorted(tasks, key=score, reverse=True)
print("導入候補順位")
for index, task in enumerate(ranked, 1):
    print(f"{index}. {task.name}: {score(task)}点")

言語はPythonで、追加ライブラリは不要。変更するのはtasksの業務名と各数値、必要ならscoreの配点である。python code01.pyで実行すると、問い合わせ転記、商談前メモ、月次請求の承認の順に点数が表示される。これは権限変更や外部送信をせず、架空データだけで試せる。空の一覧でもエラーにならず見出しだけが出ること、リスクを上げると順位が下がることを安全に確認してから、自社の候補を入れる。

基準値、役割、合格条件を先に置く

青葉設備は導入前の商談準備を三回測り、開始・終了時刻、確認時間、修正時間を残した（003）。ここを飛ばすと、導入後に「速くなった気がする」という感想しか残らない。初回は全顧客を対象にせず、一社分だけで完結させる（004）。担当者が過去の議事録と照合できる量なら、誤りの発見も修正理由の記録も容易になる。

同時に、依頼する営業企画、結果を使う営業担当、内容を確認する営業責任者を決めた（005）。誤りを見つけた際の連絡先まで決めておけば、誰かが確認したはずという空白を防げる。完了条件は「会社名、前回の合意、確認したい質問がある」「事実と仮説が分かれている」「参照資料名が付いている」とした（006）。文章のうまさではなく、目で確認できる条件にするのが要点だ。

既存の仕事へ差し込み、やめ時も決める

開始前には、利用画面、参照できるファイル、接続済みのサービス、管理者設定を確認する（007）。依頼文に書いただけで未接続の情報へアクセスできるわけではない。青葉設備は共有フォルダの議事録だけを使い、顧客管理システムへの書き込みは試行範囲から外した。成果物は新しい報告会を増やさず、既存の月曜営業会議で使った（008）。利用者のいない資料を量産しないためである。

また、追加開発を決める前に、現在の営業支援サービスの検索やCSV出力で足りないかを調べた（009）。小さな自作ツールにも、修正、保守、担当交代への備えが要る。二週間後に、準備と確認を合わせた時間、誤りの種類、実際の利用回数を見て、継続・修正・停止を決める終了条件も置いた（010）。試した仕事をやめる判断まで含めて設計することで、導入そのものが目的になるのを防げる。

初回の一週間でやること

実行順は単純でよい。初日に対象業務を一つ選び、二日目まで現在の手順と時間を記録する。三日目に一件だけ依頼し、担当者は原資料と一項目ずつ照合する。四日目に誤りと修正時間を書き、五日目に同じ条件でもう一度試す。青葉設備では初回メモの作成が速かったため、すぐ全営業へ広げそうになった。しかし確認に以前より時間がかかり、会社名の似た別顧客の記録も混じっていた。作成時間だけなら成功、確認を含めれば未合格だった。

この失敗から、計測表に「人が確認した分数」と「直した項目数」を追加した。さらに、試行中の入力、生成結果、修正版を一組で残した。何が悪かったかを依頼文だけで議論せず、実物で比較するためである。二週間後、速さが改善しても誤りが増えたなら修正、利用されなければ停止、両方が基準内なら対象を二社へ増やす。一度に全社展開せず、確認できる範囲を一段ずつ広げることが、最初の導入を現場の学習に変える。

評価会には依頼者、利用者、確認者がそろい、同じ記録を見る。誰か一人の「便利だった」で決めず、基準値との差と誤りの影響を確かめる。継続時も次の評価日を置けば、試行が惰性で恒久運用になるのを避けられる。

第2章　短い依頼でも、判断材料が欠けない型を作る

完成像と読み手を、冒頭で固定する

青葉設備で最初に失敗した依頼は「先月の営業状況をまとめて」だった。返ってきたのは文章の解説で、月次会議に貼れる表ではない。依頼の冒頭で、知りたいことに加えて、何を作るのかを伝える必要がある（011）。「月次会議で使うA4一枚」「売上、失注理由、要確認案件を表にする」のように完成像を置く。助言だけが必要なのか、保存できるファイルまで必要なのかもここで分ける。

同じ数字でも、社長、現場責任者、顧客では必要な説明が違う（012）。社長向けなら意思決定と例外を先に、現場向けなら次の操作を具体的にする。資料の役割も指定する（013）。価格は料金表、顧客の発言は最新議事録、売上は会計から出したCSVというように、どの主張をどこで確かめるかを結び付ける。社内で評価済みの完成例があれば一つ渡し、見出し、文体、情報量のどれを踏襲するかを書く（014）。ただ添付するだけでは、色をまねるのか構成をまねるの

依頼前の抜けを確認する、標準ライブラリだけの例を示す。

実行コード02｜依頼文の必須項目確認

REQUIRED = {
    "目的": "誰の何の判断・作業に使うか",
    "資料": "参照先と根拠にする情報",
    "成果物": "形式・分量・必須項目",
    "完了条件": "合格を確認できる条件",
    "権限": "閲覧・編集・送信の範囲",
}


def check_request(request: dict[str, str]) -> list[str]:
    missing = []
    for key, meaning in REQUIRED.items():
        value = request.get(key, "").strip()
        if not value:
            missing.append(f"{key}: {meaning}")
    return missing


sample = {
    "目的": "社長が月次会議で売上と課題を判断する",
    "資料": "売上.csvと最新議事録",
    "成果物": "A4一枚のMarkdown",
    "完了条件": "合計一致、事実と仮説を分離",
    "権限": "添付資料の閲覧のみ。送信禁止",
}

missing = check_request(sample)
if missing:
    print("不足項目")
    print("\n".join(f"- {item}" for item in missing))
else:
    print("必須5項目がそろっています")

言語はPythonで、前提はPython 3.9以降。変更箇所はsampleの内容で、会社の依頼文を五項目に分けて転記する。python code02.pyを実行すると「必須5項目がそろっています」と表示される。値を空文字にすると不足項目が列挙される。ファイルを変更せず、通信もしないので、実データを入れる前に架空内容で空欄と空白だけの値を確認できる。

数字のずれと、もっともらしい推測を防ぐ

集計では期間と単位を固定する（015）。「先月」だけでなく日本時間、税抜、円単位、売上計上日基準まで書けば、担当者ごとの解釈差が減る。青葉設備では受注日と計上日が混ざり、前月比が食い違った。AIの計算以前に、定義が揃っていなかったのが原因だった。

文章では確認済み事実、仮説、未確認を分ける（016）。顧客が「入力が大変」と発言したことは事実でも、原因が画面設計だという説明は仮説かもしれない。不足情報を自然な推測で埋めず「未確認」と表示し、結論を左右する質問から並べてもらう（017）。読みやすい文章ほど、推測が事実のように社内へ流通しやすいからだ。

複数部署や複数データをまたぐ依頼では、参照元、作業順、完成条件の短い計画を先に出してもらう（018）。ここで入力不足や権限不足が分かれば、完成後のやり直しを避けられる。ただし、一枚の文面修正に長い計画を求める必要はない。仕事の複雑さに合わせる。

修正と引き継ぎを次回の品質へ変える

修正時の「もっと良くして」は、評価基準を増やさない。「構成は維持し、冒頭に結論を加え、根拠のない二表現を直す」のように、合格部分と変更部分を示す（019）。青葉設備では初稿全体を毎回作り直させた結果、直っていた表まで崩れた。差分を狭めたところ、確認者も変更箇所へ集中できた。

一日で終わらない仕事には、決定事項、未完了、資料の場所、次の作業を残す（020）。担当者が不在でも確定事項と未確認事項から再開できる。公式のPromptingも目的、文脈、成果物、境界を伝える考え方を示す。ただし五項目を毎回すべて埋める必須書式という意味ではない。仕事に必要な要素を選んで使う。

依頼文を現場で育てる手順

導入時は、過去に手作業で完成させた一件を教材にする。担当者が五項目の型で依頼し、出力と正解済み成果物を並べる。差があれば「表現が違う」ではなく、入力不足、資料の選び違い、完成条件の不足に分解する。青葉設備では、顧客課題の根拠に古い議事録を使った出力が生まれた。依頼文に「最新議事録」と書くだけでは、同日に二版ある場合を区別できない。そこでファイル名と更新日を指定し、矛盾があれば新しい方へ寄せず報告する条件を加えた。

また、依頼テンプレートを長くしすぎる失敗もある。すべての注意事項を一枚へ足し続けると、重要な条件が埋もれ、担当者も更新しなくなる。共通項目は五つに保ち、集計なら期間と単位、顧客文書なら宛先と送信禁止というように、業務固有の確認だけを追加する。修正後は同じ入力で再実行し、直した箇所のほかに、合格していた部分が崩れていないかを見る。最後に日付、決定、残る不明点を引き継ぎメモへ追記する。この循環で依頼文は作文例ではなく、品質を再現する業務手順になる。

完成例も固定した正解として放置せず、承認者と更新日を付ける。古い料金や組織名が残る例を模倣すると、依頼が正しくても成果物は誤る。テンプレート、完成例、根拠資料を別物として管理し、変更時はどれを直したか残すと原因を追いやすい。

第3章　経営判断を速めるために、情報を選択肢へ変える

朝の一覧は、通知集ではなく判断待ちにする

青葉設備の社長には毎朝、メール、社内チャット、会議予定が大量に届いていた。すべてを要約しても読む量は減らない。そこで、今日社長が判断しないと誰の仕事が止まるかを基準に、予定、期限、返事待ちから三件へ絞った（021）。各項目に期限と選定理由を付ければ、単なる重要そうな話題との違いが見える。

会議前には前回議事録と最新状況を比べ、決定事項、宿題、変化、今回決める論点を整理する（022）。前回と同じ報告を聞き直す時間を減らし、冒頭で認識を揃えるためだ。大きな施策は、実施・延期・中止などの選択肢を一枚にし、費用、期待効果、前提、不確実性を同じ軸で並べる（023）。期待効果だけが数字で、リスクは感想という比較では決められない。

有力案には反対材料も集める（024）。成立しない条件、不利な事実、別案の利点を示し、それを確かめる方法まで置く。これは提案を否定する作業ではなく、見落としに早く気付くための作業だ。売上減のような数値変化も、件数、単価、継続率などへ分け、説明できる部分と未確認を分ける（025）。原因を先に断定すると、必要な追加データ

次のコードは、メモ内の年-月-日を拾い、期限がない案件を確認対象として末尾に並べる。

実行コード03｜判断待ち案件の並べ替え

from datetime import date, datetime


def parse_deadline(text: str) -> date | None:
    for word in text.replace("、", " ").split():
        try:
            return datetime.strptime(word, "%Y-%m-%d").date()
        except ValueError:
            continue
    return None


items = [
    {"案件": "倉庫更新", "担当": "田中", "メモ": "判断期限 2026-09-25 見積確認待ち"},
    {"案件": "採用媒体", "担当": "佐藤", "メモ": "候補比較後に判断"},
    {"案件": "保守契約", "担当": "伊藤", "メモ": "更新期限 2026-09-20 条件確認済み"},
]

results = []
for item in items:
    deadline = parse_deadline(item["メモ"])
    results.append({**item, "期限": deadline})

results.sort(key=lambda row: row["期限"] or date.max)
for row in results:
    deadline_text = row["期限"].isoformat() if row["期限"] else "未記載（要確認）"
    print(f"{deadline_text} | {row['案件']} | 担当:{row['担当']}")

言語はPythonで、外部ライブラリは使わない。変更箇所はitemsの案件、担当、メモである。python code03.pyを実行すると、保守契約、倉庫更新、期限未記載の採用媒体の順で表示される。通信も更新も行わない。空の一覧で何も表示されないこと、不正な日付を入れると未記載扱いになること、同一期限でも全件が残ることを確認してから、実務データへ広げる。

期限、会議、決定記録を一本につなぐ

判断待ちは期限順に並べ、担当者と不足情報を添える。期限の記載がない案件を捨てず、確認対象として残す（026）。青葉設備では契約更新日が不明な案件が一覧から消え、直前に慌てた経験があった。「日付なし」は優先度ゼロではなく、情報不足という状態である。

経営会議では報告を事前資料へ移し、各議題に「今日決めたいこと」を一つ置く（027）。決まった後は、結論だけでなく、理由、前提、見直す条件を記録する（028）。たとえば「採用媒体Aを三か月試す。応募単価と面接化率が基準を外れたら再検討」と残せば、環境が変わった時に当時の判断を責めるのではなく、条件に沿って見直せる。

社長しかできない判断を減らし、空いた時間を使う

現場から届く相談は、既定ルールで処理できるものと例外判断に分ける（029）。値引き相談なら、一定範囲は営業責任者、契約条件の変更は社長というように境界を言語化する。相談を整理する過程で、権限委譲できる仕事も見つかる。

最後に、短縮できた時間の使い道を先に予定へ入れる（030）。青葉設備では毎週二時間を重要顧客との対話に充てた。空いた時間が別の社内処理で埋まれば、準備時間を減らしても事業成果にはつながらない。判断支援の価値は、要約を多く作ったことではなく、社長が選ぶべき論点を明確にし、その後の行動へ時間を戻せたかで測る。

判断支援を日課にする小さな運用

青葉設備では、朝の担当者が前日までの資料から判断候補を作り、午前九時に社長が三件だけ確認する運用を試した。最初の週は「重要そう」という理由で案件が並び、実際の期限や止まっている担当者が分からなかった。そこで各行を、決める内容、期限、選択肢、不足情報、決めない場合の影響の五列にした。候補を減らす際も、消した案件は担当者へ戻すか翌日へ送るかを記録し、一覧から静かに消さない。

判断メモを作る人は、結論を社長の代わりに決めない。費用が空欄なら推定値で埋めず、確認先を示す。数値が変化した場合も「営業力が落ちた」と書かず、件数と単価のどちらが動いたか、その先の原因は何が未確認かを分ける。社長は選択肢を選び、理由と見直し条件を一文で残す。週末には、期限切れ、同じ相談の再発、委譲できそうな相談を見直す。

この運用の落とし穴は、一覧作成自体が新しい重作業になることだ。すべての会話を網羅せず、既存の議事録と期限表を入力に限定する。三件へ絞れない日は、優先順位の根拠が不足している合図と考える。月末には、判断までの待ち時間と、社長へ上げずに既定ルールで解決できた件数を確認する。削減した時間を顧客対話などへ実際に割り当てて初めて、情報整理が経営の行動へつながる。

なお、一覧は判断の責任を移す仕組みではない。高額契約や人事など影響の大きい案件は、元資料と担当者の説明を社長自身が確認する。整理の役割と最終決定の役割を混ぜないことが、速さを求める場面ほど重要になる。

第4章　商談準備を一枚にまとめ、顧客の言葉から提案を組み立てる

一枚のメモに、事実・仮説・質問を分ける

青葉設備の営業担当は商談前、企業サイト、過去メール、議事録を順番に開いていた。調べる人によって情報量が変わり、前回の約束を探すだけで時間が過ぎる。商談準備メモには、企業情報、過去接点、確認済みの課題、当日の質問、次の提案を一枚にまとめる（031）。新しい情報には確認日と参照先を付ける。古い会社情報を現在の事実として使わないためだ。

顧客名の照合も軽視できない。同姓同名の人物をまとめないよう、氏名だけでなく会社、部署、メールドメインなどを照合する（032）。特定できない接点は「同一人物と思われる」と統合せず、未確認のまま残す。準備を速くするために誤った人物履歴を混ぜれば、商談の信頼を損なう。

議事録からは顧客自身の発言を抜き出し、提案内容と対応させる（033）。青葉設備の架空商談で顧客が「見積もり回答まで三日かかる」と述べたなら、その発言を起点に、どの工程を短くする提案かを書く。「DXが遅れている」のように顧客が言っていない課題は仮説と表示し、当日の質問に回す。

次のコードは、入力済みの情報を事実、仮説、質問に分けたMarkdownへ整形する例である。

実行コード04｜商談前メモの分類

def build_memo(customer: dict[str, object]) -> str:
    facts = customer.get("事実", [])
    hypotheses = customer.get("仮説", [])
    questions = customer.get("質問", [])
    lines = [f"# {customer['企業名']} 商談前メモ"]
    lines.append(f"確認日: {customer['確認日']}")
    lines.append("\n## 確認済み事実")
    lines.extend(f"- {str(item)}" for item in facts)
    lines.append("\n## 仮説（商談で確認）")
    lines.extend(f"- {str(item)}" for item in hypotheses)
    lines.append("\n## 質問")
    lines.extend(f"- {str(item)}" for item in questions)
    return "\n".join(lines)


sample = {
    "企業名": "青葉設備株式会社（架空）",
    "確認日": "2026-09-18",
    "事実": ["前回は見積作成の待ち時間を課題として発言", "次回は業務責任者も参加予定"],
    "仮説": ["承認手順にも時間がかかっている可能性"],
    "質問": ["待ち時間はどの工程で発生しますか", "改善後に何を測りますか"],
}

print(build_memo(sample))

言語はPythonで、標準ライブラリだけを使う。変更箇所はsample内の企業名、確認日、三つのリストである。python code04.pyを実行すると、三分類された商談前メモが画面に出る。外部検索やファイル保存は行わない。空のリストでは見出しだけが残ること、長い根拠も省略されず保持されること、企業名がない場合はエラーとなり入力不足に気付けることを架空データで確認する。

顧客の判断軸と、条件付き試算を準備する

提案書は、既存の汎用資料で企業名だけを差し替えない。顧客が重視する価格、導入工数、現場負担、回収条件などの軸で組み直す（034）。たとえば現場の繁忙期が論点なら、多機能さより導入時期と教育負担を前に出す。ただし、判断軸も議事録に根拠があるものと営業側の仮説を分ける。

導入効果は、件数、時間、単価の根拠を示し、保守、標準、上振れなど条件を変えて試算する（035）。青葉設備が「準備時間を半減できる」と断定すれば、まだ試していない未来を実績のように扱うことになる。改善率を変更できる仮定欄を置き、既存実績と予測を別にする。商談では大きな数字を見せるより、「どの前提が変わると結論が変わるか」を共有する方が、相手は自社条件で判断しやすい。

商談準備の完了条件は、情報量の多さではない。人物を取り違えず、顧客の発言と営業側の推測を分け、確認すべき質問が残っていることだ。自動生成した一枚を担当者が原資料と照合してから持ち込む運用にすれば、速さと対話の質を両立しやすい。

商談の前日に行う確認手順

まず対象企業と参加者を特定し、企業名、部署、連絡先の識別情報を照合する。次に、最新議事録から顧客の発言と双方の宿題だけを抜き出す。その後で会社情報や過去接点を加え、各項目へ参照元と確認日を付ける。仮説は事実欄へ混ぜず、質問文に変える。最後に営業担当が原資料を開き、固有名詞、数値、前回の約束を確認する。資料がない項目は空欄を埋めず、「商談で確認」と残す。

青葉設備では、準備メモを詳しくしようとして過去三年分のニュースを載せ、肝心の前回宿題が二ページ目に埋もれた。商談中に読めないメモは、調査報告として正しくても用途に合わない。そこで一ページ目を「前回の合意、今回の目的、質問三つ、次の提案」に固定し、補足情報は別欄へ移した。質問も「課題はありますか」ではなく、「見積もり待ち三日のうち、入力、承認、送付のどこに時間がかかりますか」と、発言から確かめる形にした。

提案試算は担当者が入力値を変更できる表にし、件数と作業時間の出典を横へ置く。保守条件では改善を小さく、標準条件では試行結果を使い、上振れ条件は可能性として表示する。どの条件でも、顧客側の確認前の値を確定効果と呼ばない。商談後には、仮説のうち確認できたもの、否定されたもの、新たな宿題をメモへ戻す。これにより、次回の準備は前回の推測を使い回さず、顧客との対話で更新された事実から始められる。

準備メモの品質は、商談直後に短く振り返る。実際に役立った質問、不要だった情報、見つからなかった約束を営業担当が印を付ける。青葉設備では企業紹介を長く載せる一方、参加者の役割が欠けていたため、次回から参加者欄を必須にした。こうした修正は全案件へ一度に適用せず、次の一件で試し、確認者が読みやすさと根拠を点検する。

また、公開情報を調べた日と、顧客から直接聞いた日を区別する。情報が食い違う場合は新しい記述へ自動的に上書きせず、商談で確認する論点にする。提案の目的は相手を驚かせる情報量ではなく、相手が判断できる材料と、双方が次に確かめる事項を揃えることにある。

第5章　商談後の約束を守り、追客と引き継ぎを再現可能にする

フォロー文は「前回の合意」から始める

商談後のメールが「先日はありがとうございました」だけでは、相手は次に何を判断すればよいか分からない。青葉設備では、合意した課題、こちらの宿題、相手にお願いした確認、次の行動を短く振り返る形にした（036）。面談を提案する場合も、「見積工程の確認のため30分」のように目的と所要時間を添える。自動で文案を作っても、宛先、固有名詞、期日、添付は担当者が送信前に確認する。

追客一覧は、担当者の感覚だけで「温度が高い」と並べない。返信期限、顧客からの相談内容、次回行動の有無、未回答質問など、記録から確認できる情報で優先順位を説明する（037）。返事がないことを購買意欲の低さと断定してはいけない。青葉設備では、大口に見える案件を優先した結果、翌日が回答期限の小規模案件を遅らせた。期限と次の行動を点検軸に変えると、判断理由を営業責任者と共有できた。

次のコードは、観測できる三項目だけで今日の確認順を作る。点数は売上確度ではなく、連絡の緊急度を揃えるための社内ルール例である。

実行コード05｜追客優先度の整理

from datetime import date, datetime


def days_until(value: str, today: date) -> int | None:
    if not value:
        return None
    return (datetime.strptime(value, "%Y-%m-%d").date() - today).days


def priority(case: dict[str, str], today: date) -> tuple[int, str]:
    days = days_until(case.get("返信期限", ""), today)
    score = 0
    reasons = []
    if days is not None and days <= 1:
        score += 3
        reasons.append("返信期限が1日以内")
    if case.get("次回行動"):
        score += 2
        reasons.append("次回行動が明記")
    if case.get("未回答質問") == "あり":
        score += 1
        reasons.append("未回答質問あり")
    return score, "、".join(reasons) or "確認可能な優先根拠なし"


today = date(2026, 9, 18)
cases = [
    {"案件": "青葉設備", "返信期限": "2026-09-19", "次回行動": "日程提示", "未回答質問": "あり"},
    {"案件": "東雲食品", "返信期限": "2026-09-25", "次回行動": "", "未回答質問": "なし"},
    {"案件": "白川商事", "返信期限": "2026-09-18", "次回行動": "見積送付", "未回答質問": "なし"},
]

for case in sorted(cases, key=lambda row: priority(row, today)[0], reverse=True):
    score, reason = priority(case, today)
    print(f"{case['案件']}: {score}点 / {reason}")

言語はPythonで、標準ライブラリのみ。変更するのはtodayとcasesである。python code05.pyを実行すると、青葉設備、白川商事、東雲食品の順に点数と理由が出る。外部送信や顧客管理システムの更新はしない。不正な日付では入力誤りを示す例外が出ること、期限空欄は加点されないこと、同点でも案件が消えないことを架空データで確かめる。

失注と引き継ぎを、次の改善材料にする

失注理由は価格、時期、適合性、競合などに分け、記載がないものは不明のまま残す（038）。営業担当が「価格だと思う」と感じても、顧客の発言がなければ推測である。事実と推測を分けて集計すると、値下げで解決できる案件と、時期や機能の問題を混同しにくい。改善可能な要因は、提案時に確認できたか、説明を変えられたかまで振り返る。

受注後は、契約前の約束、納品物、期日、顧客の懸念を一つの引き継ぎメモにする（039）。青葉設備では営業が口頭で約束した初回説明会が実行担当へ伝わらず、開始直前に判明した。営業と実行担当が同じメモを確認し、曖昧な約束には確認担当と期限を付ける。文章を作ることより、双方が確認した状態までを完了とする。

顧客管理システムへ反映する前には、新規追加と既存値の変更を分け、現在値、変更値、根拠を差分で示す（040）。会話から推測した役職や導入時期を確定情報として登録しない。書き込み権限がある環境でも、下書き作成と実際の更新は別工程にし、担当者が差分を確認してから反映する。

フォロー業務で目指すのは、メールの大量作成ではない。前回の合意を守り、期限のある案件を落とさず、失注と受注の記録を次の担当者が使える形にすることだ。送信やシステム更新を自動化する前に、まず文案と差分を人が確認する運用を安定させれば、顧客対応の速度を上げながら、誤送信や誤登録の影響を抑えられる。

商談当日から引き継ぎまでの運用

商談が終わったら、担当者は当日中に合意、宿題、期限、未確認事項を四欄へ分ける。文案はその記録だけを根拠に作り、顧客が言っていない期待効果を加えない。送信前には別の担当者か責任者が、宛先、社名、日付、金額、添付を確認する。送った後は送信日時と次回行動を追客一覧へ記録する。返事が来なければ「関心なし」と更新せず、期限超過という観測事実だけを残す。

青葉設備では、優先点が高い順に自動送信する案も出た。しかし点数は連絡順を相談する材料であり、顧客との関係や文面の正しさを保証しない。期限入力が誤っていれば、誤った相手への連絡を速めてしまう。そこで朝会では上位案件の根拠を読み、担当者が連絡方法と内容を決める運用にした。点数の低い案件も週次で確認し、期限が空欄なら担当者へ戻す。

失注時は分類を選ぶだけで終えず、根拠となる顧客発言、確認日、改善可能性を残す。受注時は営業のメモを実行担当が読み、納品物と期日を復唱する。顧客管理システムへの更新案は、追加、変更、保留の三つに分け、変更前後と根拠を一覧で確認する。役職が不明なら空欄を維持する。月末には、期限超過、引き継ぎ後の確認漏れ、根拠のない更新案を数え、依頼の型や入力欄を直す。この見直しが、担当者個人の注意力に頼らない顧客対応を作る。

担当交代時には、後任がメモだけで次の行動を説明できるかを確かめる。説明できなければ、情報量を増やす前に、合意と未確認の境界、担当、期限を補う。フォロー文、追客一覧、引き継ぎメモ、更新差分が同じ約束を指している状態が、完了の目安となる。

第6章　集客を「発信量」ではなく商談までの流れで見る

問い合わせの現場が、企画会議の出発点になる

従業員25人の架空企業「北町設備」は、毎週ブログを更新していた。しかし編集会議で出るのは「今月は何を書こうか」という悩みばかりだ。そこで営業日報から、顧客が繰り返す質問を拾った。「工事中も営業できるか」「見積もり後に追加費用は出るか」「古い設備でも部品はあるか」。商品に近く、契約前の不安を解く質問から記事にする。これが【041】顧客の質問から企画を作る、の実務である。検索されそうな言葉を並べるだけでは、読者の切実さと会社の強みが結び付かない。

記事には一つだけ読後の行動を置く【042】。追加費用の記事なら「料金条件をまとめた資料」、工事工程の記事なら「現地調査の相談」が自然だ。全部の記事末に同じ問い合わせボタンを置くと、読者には急に売り込まれたように映る。本文で解いた疑問と次の行動が連続しているかを確認したい。

北町設備は企画表に「顧客の原文」「答えられる根拠」「想定読者」「読後の行動」の四列を作った。営業が「価格を知りたい」と書いたときも、電話記録を読むと本当の質問は「休業損失を含めて予算内か」だった。そこで価格表ではなく、工程別に休業の要否を示す記事へ変えた。質問を整いすぎたマーケティング用語へ直す前に、顧客が口にした状況を残すと、企画の焦点がずれにくい。採用しない質問にも理由を付ければ、声の大きい人の思いつきだけで発信予定が変わるのを防げる。

比較記事では、さらに慎重さが要る【043】。料金は税の扱い、契約期間、含まれる作業を同じ条件にし、公式情報の確認日を残す。確認できない欄は推測で埋めない。北町設備が競合の旧料金を載せかけたとき、公開前の確認日欄が空だったため止められた。空欄は失敗ではなく、未確認を可視化する安全装置になる。

一つの取材を増やしても、事実は増やさない

現場責任者への60分の取材は、長い記事、短いSNS投稿、FAQに展開できる【044】。ただし媒体に合わせて情報量を変えても、工期や保証範囲、事例の数字を変えてはいけない。元発言と確認済み資料を共通の台帳に置き、各原稿がどこを参照したか残す。さらに、良い過去原稿、避けたい誇張語、顧客をどう呼ぶかを例で共有する【045】。「圧倒的」「必ず」といった言葉を禁じるだけでなく、「当社」より「私たち」を使うなど、採用する表現も示すと修正が減る。

実績数字は印象が強いぶん、間違いも広がりやすい。【046】では対象期間、母数、測定方法まで元資料へ戻る。「作業時間を最大50％削減」は、誰のどの作業を何件測ったのか。「平均」なら外れ値を含むのか。答えられない数字は、派手でも掲載を保留する。生成した文章は候補であり、事実確認と公開範囲の判断は会社側の仕事だ。

LPとフォームは、見た目より申込の完走を試す

新サービスのLPは、一つの読者と一つの訴求で小さく試す【047】。北町設備なら「店舗を閉めずに設備更新したい飲食店」に絞り、必要情報、相談ボタン、完了までの道筋を紙に描く。最初から全業種向けにすると、誰の不安にも具体的に答えられない。

完成画面を見て安心せず、架空データでフォームを送る【048】。必須欄を空にする、電話番号を誤る、戻る操作をする、完了画面と通知先を確認する。美しい画面と、申込が担当者へ届くことは別の品質だ。顧客情報を使わずに試し、公開や外部送信は権限を持つ担当者が確認してから行う。

判断指標も訪問数だけでは足りない。【049】訪問、問い合わせ、有効商談を流入元別に分けると、SNSは訪問が多いが商談が少なく、紹介は少数でも商談につながる、といった違いが見える。次の例は架空データだけでその比率を計算する。

実行コード06｜流入別商談率

from collections import defaultdict

visits = [
    ("検索", 120, 9, 4),
    ("紹介", 30, 8, 6),
    ("SNS", 200, 10, 2),
    ("検索", 80, 5, 3),
]

totals = defaultdict(lambda: [0, 0, 0])
for source, visit, inquiry, deal in visits:
    if min(visit, inquiry, deal) < 0:
        raise ValueError("件数は0以上にしてください")
    if not (deal <= inquiry <= visit):
        raise ValueError(f"段階の件数が逆転しています: {source}")
    row = totals[source]
    row[0] += visit
    row[1] += inquiry
    row[2] += deal

print("流入元,訪問,問い合わせ,有効商談,商談率")
for source in sorted(totals):
    visit, inquiry, deal = totals[source]
    rate = f"{deal / visit:.1%}" if visit else "算定不可"
    print(f"{source},{visit},{inquiry},{deal},{rate}")

言語はPython、標準ライブラリのみで、前提は件数が「商談≦問い合わせ≦訪問」であること。変更箇所はvisitsの架空行だけに限定できる。python code06.pyで実行し、流入元ごとの件数と商談率が出ればよい。安全な確認方法は架空データで、訪問ゼロは算定不可、負数と段階逆転はエラーになることを別途試すことだ。

最後に【050】改善案は一度に一つ変える。見出し、訴求、フォームを同時に直すと、何が効いたか分からない。「資料ボタンの文言だけ」「2週間」「有効商談率を見る」と記録する。少ない訪問で勝敗を急がず、営業現場の声も合わせる。集客の改善とは大量に発信することではなく、質問、根拠、導線、商談という一本の流れを少しずつ確かにすることだ。

検証票には変更前の画面、変更理由、開始日、終了条件、途中で起きた出来事も残す。期間中に展示会や紹介キャンペーンがあれば、数字の差を見出し変更の成果とは断定できない。経営者が見るべきなのは一回の勝ち負けではなく、次の判断に使える記録が増えたかである。成果を誇張せず、反応が少なかった企画も「誰には響かなかったか」という学びとして残す。

第7章　指標の定義とデータ品質を、集計の前に整える

同じ「売上」が二つある会議

架空の卸売会社「港屋フーズ」では、営業部の月商は受注時点、経理部の売上は出荷時点だった。社長会議で数字が合わず、担当者は毎月説明に追われた。先に必要なのは精巧なグラフではない。【051】売上、受注、商談、有効リードについて、含むもの、除くもの、計上日、責任部署を一枚の定義表にすることだ。同じ名前で異なる数字を表示すると、会議は原因分析ではなく正しさの争いになる。

定義が決まったら【052】元データを保全する。受領したCSVを直接開いて上書きせず、読み取り用の原本と加工用コピーを分け、ファイル名、受領日時、処理日を記録する。集計後に「元は何だったか」へ戻れなければ、訂正も監査もできない。小規模企業でも、原本、処理手順、出力の三つを同じ案件フォルダにそろえるだけで追跡性は大きく変わる。

港屋フーズでは、月末23時の受注を営業が当月、経理が翌月に入れていた。どちらかを即座に誤りと決めず、会議の目的を分けた。営業活動を見る資料は受注日、会計数値を見る資料は出荷日を採用し、画面名にも基準を入れた。定義表には具体例と反例を載せる。「有効リード」は担当者が連絡でき、対象地域と予算条件を満たすもの。「名刺交換だけ」は含めない。この粒度まで書くと、新人も同じ分類を再現できる。定義変更は過去値との比較を壊すため、適用開始月と承認者も必要になる。

変換作業の前後には、行数、列数、金額合計を記録する。コピーを作っただけでは保全にならず、どの処理がどの原本を使ったか結び付いて初めて追跡できる。港屋フーズは受領ファイルを年月別フォルダへ置き、加工担当が「列名統一」「日付形式変換」と処理順を短く記した。後日、前月の数字が変わったとき、再送された原本を使ったことが分かり、差異を説明できた。原本には訂正を加えず、訂正版を別ファイルとして受領日時とともに残した。

表記ゆれは機械的に寄せすぎない

「港屋食品」「（株）港屋食品」「港屋食品東京」は同じ会社かもしれない。しかし似ているだけで統合すると、別支店や別法人を混ぜる危険がある。【053】社名、部署名、日付の変換表を用意し、法人番号や顧客IDで確認できたものだけ統一する。曖昧な候補は「保留」に置き、人が判断する。

重複も同じだ。【054】注文番号や顧客IDのような業務上の識別子を使う。同日・同額の注文が二つあっても、定期購入なら両方が正しい可能性がある。自動削除は手間を減らすように見えて、売上そのものを消す。候補、判定理由、確認者を残し、削除は別の意思決定にする。

確認の優先順位も決めておく。IDが完全一致し、住所と電話も一致する行は高優先、社名だけ似る行は低優先として保留する。担当者が判断した結果は変換表へ戻し、次月に同じ確認を繰り返さない。一方、合併や支店統合で関係が変わることもあるので、判断日と根拠資料を消さない。「一度統一したから永久に

空欄とゼロは、経営上まったく違う

【055】未入力、未取得、該当なし、実際のゼロを区別する。港屋フーズで粗利欄が空の案件をゼロ扱いした結果、ある部門の平均粗利が急落して見えた。実態は仕入データの到着待ちだった。ゼロは「測った結果ゼロ」、空欄は「まだ分からない」。不明を無理に数値へ変えず、欠損件数と理由を一緒に報告するほうが、社長は数字の確からしさを判断できる。

次のコードは、架空の4行を使い、欠損と顧客ID重複を候補として出す。削除や補完は行わない。

実行コード07｜欠損と重複の確認

from collections import Counter

rows = [
    {"id": "C001", "company": "青空商事", "sales": "120000"},
    {"id": "C002", "company": "みどり企画", "sales": ""},
    {"id": "C002", "company": "みどり企画", "sales": "0"},
    {"id": "", "company": "架空製作所", "sales": "80000"},
]

counts = Counter(row["id"] for row in rows if row["id"])
missing = []
duplicates = []
for number, row in enumerate(rows, start=1):
    if not row["id"]:
        missing.append((number, "id", "未入力"))
    if row["sales"] == "":
        missing.append((number, "sales", "未取得"))
    elif int(row["sales"]) == 0:
        print(f"行{number}: 売上0は実値として保持")
    if row["id"] and counts[row["id"]] > 1:
        duplicates.append((number, row["id"], "顧客ID一致"))

print("欠損候補:", missing)
print("重複候補:", duplicates)
print("自動削除はせず、担当者確認へ回します")

言語はPython、標準ライブラリのみ。前提はidが業務上の顧客識別子で、salesの空文字が未取得を表すこと。変更箇所はrowsの架空データである。python code07.pyを実行し、ゼロ保持、欠損候補、重複候補が別々に表示されるのが期待出力だ。安全な確認方法はコピー上で実行し、候補件数を手計算と比べ、原本を変更していないことを確かめること。

データ品質は、きれいな表を作る作業ではない。どの数字を信じてよいか、どこから先は人の確認が要るかを明らかにする仕事だ。定義表の承認者を決め、変換表には変更日を持たせ、欠損と重複の候補を会議前に共有する。すると数字が一致しないときも、誰かを責めず「定義」「入力」「取得」「変換」のどこで差が出たかを調べられる。経営判断の速度は、集計処理の速さより、疑問が生じたときに根拠へ戻れる速さで決まる。

月次会議には、売上表と並べて品質メモを一枚付ける。「粗利未取得3件、重複候補2件、定義変更なし」のように短くてよい。欠損が重要案件へ偏っていれば、全体の欠損率が低くても判断を保留する。逆に少額案件の住所欄が欠けていても、売上合計への影響はないかもしれない。件数だけで品質を評価せず、どの判断に影響する欠損かを見る。これにより社長は、確定値、暫定値、確認中を区別して会話できる。

第8章　毎月の集計を再現し、判断につながる画面にする

月初の職人芸を、繰り返せる手順へ変える

架空の内装会社「木葉デザイン」では、管理担当者が毎月三つのCSVをコピーし、列を削り、月別売上を作っていた。本人は20分でできるが、休むと誰も再現できない。そこで【056】同じ加工を繰り返し実行できる形にする。入力ファイルの名前と列、出力先、実行方法、エラー時の止まり方まで残す。「自動化した」ではなく、来月、別の人が同じ結果を得られることが完了条件だ。

ただし、処理が最後まで動いたことと、数字が正しいことは違う。【057】集計前後の件数、金額合計、対象期間を照合する。4件が3件になったなら、重複を消したつもりでも正当な注文を落とした可能性がある。差が出たら差額だけでなく、該当する注文番号までたどれるようにする。社長へ提出する前に「元帳4件・40万円、集計4件・40万円」のような照合欄を置く。

木葉デザインは、まず担当者の手作業を横で観察した。CSVを開く前に対象月を確認し、取消行を除き、担当部署のない行を別表へ移す。本人が無意識にしていた判断を一つずつ手順にしたところ、「取消」の表記が二種類あると判明した。自動化は操作を速くするだけでなく、暗黙の判断を発見する機会になる。入力列が不足した場合は処理を続けず、何が足りないか表示する。誤った完成表を作るより、理由を示して止まるほうが安全だ。

月次実行票には、対象期間、入力ファイル、実行者、出力先、照合結果を残す。再実行した場合は古い出力を黙って上書きせず、版を区別する。前月のファイルを誤って選んだ事故も、対象期間の最小日と最大日を出力すれば発見しやすい。自動処理の前後に人が見る関門を置くことで、速さと説明可能性を両立できる。

異常値は、削除対象ではなく質問の入口

一件だけ500万円の受注があれば、平均を乱す異常値に見える。しかし実際は重要な大口案件かもしれない。【058】極端な値や急増は理由付きの確認候補にし、元データを保持する。入力桁の誤りか、事業の変化かは現場に聞かなければ分からない。自動削除すると、まさに社長が知るべき変化を画面から消してしまう。

異常候補には、平均との差だけでなく確認理由を添える。「通常上限の3倍」「前月同社比で急増」と書けば、現場はどこを見るか分かる。確認後は「入力誤りで訂正」「大型案件として採用」の結果を残す。閾値も永久固定ではない。事業規模が変われば通常範囲は変わるため、四半期ごとに候補が多すぎ

社長画面は五つの数字より、その先の行動を設計する

【059】画面に置く指標は判断に必要なものへ絞る。売上、粗利、受注残、資金見通し、要確認案件など、会社の今の課題に合わせて選ぶ。数字をクリックしたら担当者や元データへ戻れる構造が大切だ。「粗利が悪化」の赤表示だけでは、会議で誰に何を聞くか決められない。要確認案件を金額順に並べ、案件名、責任者、次の確認日を見せれば行動につながる。

画面には【060】更新日時と取得状態も表示する。会議当日の画面でも、データ取得が前月で止まっていれば古い。取得失敗をゼロ表示すると「売上なし」と誤認されるため、「未更新」「取得失敗」と明記し、最後に成功した日時を残す。鮮度が分からない数字は、精密に見えても意思決定には使えない。

次は、架空元帳を月別集計し、元の件数と金額へ照合する最小例だ。

実行コード08｜月次集計の照合

from collections import defaultdict
from datetime import date, datetime, timezone

ledger = [
    ("2026-07-03", "A-001", 120000),
    ("2026-07-18", "A-002", 80000),
    ("2026-08-02", "A-003", 150000),
    ("2026-08-29", "A-004", 50000),
]

monthly = defaultdict(lambda: {"count": 0, "sales": 0})
for date_text, order_id, amount in ledger:
    parsed_date = date.fromisoformat(date_text)
    month = parsed_date.strftime("%Y-%m")
    monthly[month]["count"] += 1
    monthly[month]["sales"] += amount

source_count = len(ledger)
source_total = sum(row[2] for row in ledger)
result_count = sum(item["count"] for item in monthly.values())
result_total = sum(item["sales"] for item in monthly.values())

for month in sorted(monthly):
    item = monthly[month]
    print(month, item["count"], item["sales"])
print("件数照合:", source_count, result_count)
print("金額照合:", source_total, result_total)
print("照合結果:", "一致" if (source_count, source_total) ==
      (result_count, result_total) else "不一致")
print("更新日時(UTC):", datetime.now(timezone.utc).isoformat(timespec="seconds"))

言語はPython、標準ライブラリのみ。前提は日付が年-月-日、金額が整数であること。変更箇所はledgerの架空行で、python code08.pyと実行する。月別2件ずつ、合計4件・40万円、照合結果「一致」とUTC更新日時が期待出力だ。安全な確認方法は原本のコピーを使い、月境界と不正日付、マイナス金額、空ファイルを試すこと。

木葉デザインでは、担当者が休んだ月を想定し、別の社員が説明書だけで実行する。そこで入力列名の違いに気づけば、本番前に手順を直せる。ダッシュボードの価値は、グラフの多さではない。集計が再現でき、元帳と一致し、異常を隠さず、いつの数字か分かり、問題の担当者へたどれること。この五つがそろって初めて、月次会議は数字を作る時間から、数字を使う時間へ移る。

画面公開後には、会議で実際に使われた指標を記録する。毎月表示しても誰も判断に使わないグラフは外し、赤信号を見た後に必ず開く案件一覧を上へ移す。指標を増やす依頼には「その数字が動いたら何を決めるか」を尋ねる。答えがなければ、詳細資料に置く。社長画面の余白は不足ではなく、重要な変化を目立たせるための設計である。

月次の終了条件は、出力完了ではなく「照合済み、取得状態表示済み、要確認案件に担当者設定済み」とする。数字を見る人と直す人をつなぐところまでが集計である。

第9章　一画面の社内ツールから、使える仕組みを育てる

最初の要望を一つに絞る

架空の印刷会社「風見プリント」は、見積もり、在庫、顧客管理を一度に作ろうとして要件が止まった。そこで【061】最初の目的を「数量と単価から見積金額を出す」に絞る。一画面・一目的なら、現場は翌週にも触れ、間違いを具体的に言える。基幹システムの完成図を議論し続けるより、小さな試作で業務ルールの曖昧さを発見するほうが早い。

【062】入力と出力は文章だけでなく具体例にする。「単価1200円、数量3、値引10％なら3240円」。端数処理は一円単位、並び順は入力順、と期待結果まで示す。開発側が仕様を理解したつもりでも、税の計算順や値引上限で認識はずれる。例があれば、画面を作り込む前にその差を直せる。

風見プリントは受付、営業、経理の三人に同じ例を見せた。受付は数量の空欄を一時保存したい、営業は値引理由を残したい、経理は承認前の金額を売上へ含めたくないと言った。機能一覧だけを集めると要求が膨らむため、最初の試作では計算とエラー表示だけに限定し、保存と承認は次の検討へ回した。見送った要望も理由と再検討条件を記録すれば、無視されたという不信を生みにくい。

試作では【063】架空データを使う。「青空商事」「案件A」のような実在しない名前で、画面と処理を確かめる。顧客名、単価、担当者の個人情報を公開デモに持ち込む必要はない。業務データを扱う版へ進むのは、保存場所と閲覧者を決めた後でよい。

架空データは正常な一件だけでなく、現場の幅を表す。商品一行、複数行、摘要が長い案件、数量ゼロ、上限直前を用意する。名前だけ伏せた実データは、自由記述欄に住所や電話が残ることがあるため安全な架空化とは限らない。最初から作り物として設計し、公開デモと社内検証のデータを分ける。テスト後に初期化できる手

修正は不具合の周囲だけに留める

値引後の端数が一円ずれる不具合なら、再現入力、期待値、実際値をそろえる。【064】原因となる丸め処理を直し、関係のない帳票や顧客検索まで変更していないか差分を見る。ついでの改良を混ぜると、問題が再発したときに戻す範囲が広がる。小さな変更は、効果が小さいのではなく、原因と結果を追いやすい。

正常例が通っただけでは完成ではない。【065】空欄、ゼロ、上限、上限超過、重複を試す。見積もりでは、数量ゼロを許すのか、単価の負数を拒否するのか、値引率の上限を誰が決めるのかが経営ルールになる。次のコードは値引率30％、数量1000を上限とした運用提案であり、実在企業の確定仕様ではない。

境界テストの結果は「成功・失敗」だけで書かない。入力、期待、実際、判定、確認者を一行にする。空欄でエラーが出ても、利用者が修正場所を理解できなければ業務は止まる。ゼロを許す場合も、無料提供なのか数量未確定なのか意味を決める。重複クリックで同じ見積もりが二件できないか、戻る操作で値引が二重適用されないかも、画面化する段階で試す。

実行コード09｜見積計算の境界テスト

from decimal import Decimal, InvalidOperation, ROUND_HALF_UP

MAX_QUANTITY = 1000

def quote(unit_price, quantity, discount_rate=Decimal("0")):
    if unit_price is None or quantity is None:
        raise ValueError("単価と数量は必須です")
    if type(quantity) is not int:
        raise ValueError("数量は整数で入力してください")
    try:
        price = Decimal(str(unit_price))
        rate = Decimal(str(discount_rate))
    except (InvalidOperation, ValueError):
        raise ValueError("単価と値引率は数値で入力してください") from None
    if not price.is_finite() or not rate.is_finite():
        raise ValueError("単価と値引率は有限値にしてください")
    if price < 0 or not 0 <= quantity <= MAX_QUANTITY:
        raise ValueError("単価または数量が範囲外です")
    if not Decimal("0") <= rate <= Decimal("0.3"):
        raise ValueError("値引率は0〜30%です")
    amount = price * quantity * (Decimal("1") - rate)
    return amount.quantize(Decimal("1"), rounding=ROUND_HALF_UP)

cases = [
    ("通常", 1200, 3, "0.1"),
    ("数量ゼロ", 1200, 0, "0"),
    ("上限", 1, 1000, "0.3"),
    ("空欄", None, 2, "0"),
    ("上限超過", 1, 1001, "0"),
    ("NaN", "NaN", 1, "0"),
    ("小数数量", 100, 1.5, "0"),
]

for name, price, quantity, rate in cases:
    try:
        print(name, quote(price, quantity, Decimal(rate)))
    except ValueError as error:
        print(name, "エラー:", error)

言語はPython、標準ライブラリのみ。前提は金額を円単位で四捨五入し、数量は整数、数量上限1000、値引上限30％とすること。変更箇所はMAX_QUANTITY、値引率条件、casesである。python code09.pyを実行し、通常3240円、数量ゼロ0円、上限700円になり、空欄、上限超過、NaN、小数数量はエラーになるのが期待出力だ。安全な確認方法は架空データだけを使い、負数、無限値、30％ちょうど、30％超、真偽値も試し、経理担当が計算機で照合すること。

この試作で重要なのは、コードの短さではなく会話が具体化する点だ。「数量ゼロは下書きとして保存したい」「30％超は部長承認にしたい」と、現場が操作を見ながら決められる。決定は仕様表へ戻し、サンプルと期待結果も更新する。小さなツールは大きな構想の縮小版ではない。一つの困りごと、一つの計算、一つの責任者を結び、使いながら会社固有のルールを発見するための道具である。

試用期間は一週間とし、旧計算表も参照できる状態で結果を突き合わせる。差が出た案件は、どちらを正しいと決めつけず計算順を確認する。問い合わせ窓口を一人決め、要望と不具合を分けて記録する。「色を変えたい」と「金額が違う」を同列に扱わない。利用頻度、計算差異、入力に迷った回数を見て次の投資を決めれば、多機能化そのものが目的になるのを防げる。

正式採用の判断では、速くなったという感想だけに頼らない。十件の見積もりで旧手順との金額差がないか、入力途中の離脱はないか、修正履歴を追えるかを見る。

また、使わない決定も成功になり得る。例外処理が多く、毎回手修正が必要だと分かったなら、試作は投資を止める根拠を作った。要望を追加して延命する前に、対象業務をさらに狭めるか、既存手順へ戻すかを選ぶ。小さく始める意味は、小さな費用で学び、撤退も選べることにある。

第10章　検証・保守・引継ぎまでを完成条件にする

作った人ではなく、使う人の操作で確かめる

架空の修理会社「朝凪サービス」は、案件管理ツールを社長が試して「問題なし」と判断した。しかし受付担当は、完了ボタンの前に写真登録が必要だと分からず作業を止めた。【066】現場担当者が説明なしで、入力から完了まで操作する。迷った場所、押し間違えた場所、助けを求めた言葉を記録する。機能が動くことと、利用者が仕事を終えられることは別の検証だ。

公開前には【067】役割別のアクセス制御を確かめる。ログインできるかだけでなく、受付が経理データを見られないか、A支店がB支店の顧客を検索できないか、閲覧のみの人が更新できないかを試す。権限表に「役割、閲覧範囲、更新範囲、確認者」を並べ、担当者が架空アカウントで検証する。本番の顧客情報を使って権限試験を始めてはいけない。

操作確認シートは「自由に触ってください」ではなく、日常の順番で作る。新規依頼を登録し、担当者へ割り当て、写真を添付し、完了へ進め、一覧から探し直す。途中で電話が入った想定で保存して再開する。観察者はすぐ助けず、どの表示で止まったかを記録する。五人中三人が同じ場所で迷えば、教育不足ではなく画面や言葉の問題かもしれない。説明書を厚くする前に、表示を直せないか考える。

戻せる変更と、説明できる費用を残す

【068】変更内容と理由を履歴に残し、正常だった版を保存する。「9月18日、端数処理を四捨五入へ変更。経理確認済み」のように、何を、なぜ、誰が確かめたかを書く。障害時に戻す手順も実際に小さな環境で試す。複数機能を一度に変えなければ、戻す単位も小さくなる。

戻す判断の基準も事前に決める。保存できない、他部署の情報が見える、金額が一致しない場合は利用を止めて正常版へ戻す。一方、表示のずれなら業務継続しながら修正できるかもしれない。重大度、連絡先、一次対応の期限を表にすると、障害時に社長の到着を待たず動ける。復旧後は原因、影響した件数、再発防止を履歴へ追加する。

【069】維持費は、導入時の金額だけでは分からない。ホスティング、外部API、保存容量、バックアップ、担当者の保守時間を固定費と従量費に分ける。無料の試作と、毎日使う運用版の条件を混ぜない。料金が未確認なら仮定を明記し、契約前に公式情報を再確認する。ここで示すのは費用項目の運用提案で、特定製品の料金保証ではない。

費用表には現在額だけでなく増える条件を書く。利用者数、処理件数、保存年数が倍になったとき何が変わるか。担当者が月二時間で済む前提も、問い合わせが増えれば崩れる。金額未確定の欄をゼロにせず「見積待ち」とし、誰がいつ確認するかを置く。停止時のデータ取り出しや移行作業も、継続判断に必要な

社長が不在でも復旧できる状態へ

最後の【070】は、起動方法、データの場所、依存サービス、障害対応を別の担当者へ渡すことだ。朝凪サービスでは、社長のパソコンでしか起動方法が分からず、休暇中に月次処理が止まった。説明書を作るだけでなく、引継ぎ相手が新しい環境で起動し、バックアップの場所を指し、問い合わせ先を選べるか試す。秘密情報そのものは文書へ貼らず、安全な保管場所と取得手順を示す。

次のコードは、架空の引継ぎフォルダに必要な文書と項目がそろうかを確認する。実システムや外部サービスは変更しない。

実行コード10｜引継ぎ文書の確認

from pathlib import Path
from tempfile import TemporaryDirectory

required = {
    "README.md": ["起動方法", "データの場所", "障害対応"],
    "ACCESS.md": ["閲覧権限", "更新権限"],
    "CHANGELOG.md": ["変更理由", "戻し方"],
    "COST.md": ["固定費", "従量費", "保守工数"],
}

sample = {
    "README.md": "起動方法\nデータの場所\n障害対応\n",
    "ACCESS.md": "閲覧権限\n更新権限\n",
    "CHANGELOG.md": "変更理由\n戻し方\n",
    "COST.md": "固定費\n従量費\n保守工数\n",
}

missing = []
with TemporaryDirectory() as workdir:
    base = Path(workdir)
    for name, text in sample.items():
        (base / name).write_text(text, encoding="utf-8")
    for name, terms in required.items():
        path = base / name
        text = path.read_text(encoding="utf-8") if path.exists() else ""
        for term in terms:
            if term not in text:
                missing.append(f"{name}: {term}")

print("引継ぎ確認:", "合格" if not missing else "要修正")
print("不足:", missing)

言語はPython、標準ライブラリのみ。前提は一時領域へ架空サンプルを作れること。変更箇所はrequiredとsampleである。python code10.pyを実行し、「引継ぎ確認: 合格」「不足: []」が期待出力だ。安全な確認方法は項目を一つ消した架空コピーで「要修正」になることを確かめること。キーワードの存在は内容の妥当性や実動を保証しないため、実運用では文書を読んだ後に起動・復旧を別途試す。認証情報は文書に書かない。

保守可能性は、将来の問題をすべて予測することではない。問題が起きたとき、影響範囲を限定し、正常版へ戻り、責任者へ連絡し、別の人が再開できる状態を作ることだ。利用者テスト、権限テスト、変更履歴、費用表、引継ぎ演習を公開条件に含めれば、「作った人しか分からない」は減らせる。試作から業務データを扱う段階へ進む前に、現場、管理者、保守担当の三者で確認する。それが社内ツールを一時的な便利さで終わらせず、会社の仕組みにする最後の工程になる。

引継ぎ完了日は、文書を渡した日ではなく、後任が一人で定例作業を終えた日にする。朝凪サービスは、前任者が見守る一回目、前任者が不在の二回目を実施し、質問を説明書へ戻した。連絡先や契約情報には更新期限を設け、四半期ごとに確認する。人が替わっても手順が残り、手順が古くなったら気づける。この循環まで設計して、初めて引継ぎは一度きりの儀式ではなく保守の仕組みになる。

第11章　「うまくいった」を標準手順に変える

社長の頭の中を、誰でも確認できる形へ

AI活用が属人化する会社では、担当者が毎回「前と同じ感じで」と頼み、結果が悪いと文章を足して直している。これでは担当者が休むと止まり、なぜ前回は成功したのかも説明できない。最初に整えるのは高度な自動化ではなく、仕事の合格条件である。

たとえば従業員30人の卸売会社で、月曜朝の営業会議用に案件一覧を作るとする。社長は「重要案件をまとめて」と言うが、営業部長は売上見込み300万円以上、経理は入金予定日が近い案件を重要と考えていた。AIの出力が毎回揺れた原因は能力ではなく、社内で定義が一致していなかったことである。目的、入力、手順、完成条件を一枚に書くと、議論すべき点が見える。

項目071では、用語、確認方法、完成条件などプロジェクト全体の共通ルールをAGENTS.mdへ短くまとめる。ただし、AGENTS.mdは作業者への指示であり、アクセス制御ではない。「顧客台帳を変更しない」と書くだけで変更権限が消えるわけではなく、実際のファイルの読み書き制限、サンドボックス、承認設定などは別に管理する。

項目072は、毎回同じ説明を要する仕事をスキルにする考え方である。入力、参照資料、処理手順、完成条件を再利用できる単位にする。項目073では「月曜会議の案件要約に使う」「営業台帳CSVが必要」「顧客への連絡や台帳更新は対象外」と適用条件を明記する。スキルは手順を再利用する仕組みであって、定刻に勝手に動く機能ではない。定期実行は次章で別に設計する。

成功例より、止まれる失敗例が重要

項目074は通常、資料不足、情報矛盾の三条件で試す。先の会社では、正常なCSVだけで試したため、翌週に「見込み金額」列が抜けたファイルをゼロ円として集計してしまいました。正しい対応は推測して続けることではなく、「列がないので停止。対象ファイルと不足列を報告」である。顧客名が二つの資料で食い違う場合も、都合のよい方を選ばず、矛盾箇所を示して確認を求める。

標準手順には、目的、入力、手順、完成条件、適用条件、対象外、失敗時の七つを置くと実務で使いやすくなる。完成条件は「分かりやすい」では弱く、「対象件数と合計額が元表と一致し、各行に根拠行番号がある」のように観察可能にする。失敗時には、止める条件、残す記録、判断する人まで書く。

実践では、最初から立派な手順書を作らなくて構わない。担当者が実際に一件処理しながら、判断した箇所を付箋のように書き出す。「更新日が同じ案件は担当営業へ確認する」「失注理由が空欄なら集計から除かず不明として数える」といった暗黙知である。次に別の担当者がその文章だけを見て同じ仕事を行い、質問が出た箇所を追記する。ここで質問ゼロを目指すより、質問が出たら安全に止まれることを優先する。

社長が確認すべきなのは、文章の細かさより三つである。第一に、この手順の結果がどの意思決定に使われるか。第二に、間違った場合の最大影響は何か。第三に、最終責任者は誰か。社内会議の参考表と、顧客へ渡す見積書では必要な確認水準が違う。影響が大きい仕事ほど、入力の版を固定し、照合者を分け、承認前には外へ出ない流れにする。

改訂日と変更理由も残す。現場が手順を守れないとき、怠慢と決めつけず、入力が変わった、例外が増えた、完成条件が現実と合わない可能性を調べる。標準化とは人を手順に縛ることではなく、判断の差を発見できる共通の物差しを持つことである。月に一度、実際に起きた例外を見直し、頻出するものだけ正式な分岐へ加える。

導入会議では、正常例一件、欠損例一件、矛盾例一件を同じ場で動かす。正常例が合格し、欠損例が止まり、矛盾例が確認依頼になるなら、手順の輪郭が見えている。逆に三件ともそれらしい文書が出るなら、停止条件が弱いという判断である。この確認を終えてから、再利用回数や自動化の価値を考える。

製品上の扱いは、AGENTS.mdとSkillsの公式説明で確認

次のコードは七項目の欠落と空欄を検査する。Python標準ライブラリだけで動き、ファイル変更や外部送信はない。

実行コード11｜手順書の必須項目確認

"""標準手順に必須項目があるかを点検する。Python 3、標準ライブラリのみ。"""

REQUIRED = {
    "目的": "誰の何の判断・作業に使うか",
    "入力": "必要な資料やデータ",
    "手順": "担当者が再現できる処理順",
    "完成条件": "合格を判断できる基準",
    "適用条件": "いつ使うか",
    "対象外": "使ってはいけない仕事",
    "失敗時": "止め方と報告内容",
}


def inspect(procedure):
    missing = []
    blank = []
    for key in REQUIRED:
        if key not in procedure:
            missing.append(key)
        elif procedure[key] is None or not str(procedure[key]).strip():
            blank.append(key)
    return missing, blank


sample = {
    "目的": "社長が週次会議で受注見込みを確認する",
    "入力": "営業台帳CSV（顧客名は顧客IDへ置換）",
    "手順": "対象週を絞り、金額を合計し、元データと照合する",
    "完成条件": "件数・合計額が元データと一致する",
    "適用条件": "毎週金曜の営業会議前",
    "対象外": "顧客への送信、CRMの更新",
    "失敗時": "処理を止め、不足列と対象ファイル名を報告する",
}

missing, blank = inspect(sample)
if missing or blank:
    print("要修正", {"不足": missing, "空欄": blank})
else:
    print("合格: 必須7項目を確認しました")

前提はPython 3である。変更箇所はsampleの値だけである。python code11.pyで実行し、期待出力は「合格: 必須7項目を確認しました」。値を空欄にすれば「要修正」と表示される。これは文書の形式検査であり、内容の妥当性や権限を保証しない。担当者が実データ、完成例、アクセス設定を別に確認する。

第12章　定期実行は「時計」より再実行を設計する

手動で三回成功してから予定表に載せる

定期実行の失敗は、時刻設定より前に始まっている。ある設備会社は毎週月曜7時に案件集計を動かしたが、初回に共有フォルダが見えず、二回目は祝日を前営業日として扱えず、三回目は通知が全社員へ届いた。手作業なら担当者が気づく条件を、予定だけ先に自動化したためである。

項目075では通常の依頼として複数回試し、出力が安定してから定期実行へ移す。最初の数回は人が結果を確認する。項目076では曜日、時刻、タイムゾーン、対象期間を明記する。「毎朝」ではなく「平日7時、日本時間、前営業日分」と書き、祝日や月初の扱いも決める。日付の境界は、売上を二重計上する原因になる。

項目077は実行場所の確認である。ローカル実行はPCやアプリが起動し、必要なファイルへ到達できることが前提である。ウェブ側の定期実行なら、そこから参照できる資料と接続権限が必要である。手元のデスクトップにある表を、別環境が当然読めると思ってはいけない。項目078では通知を行動が必要な場合に絞る。「完了しました」を毎日送ると、重大なエラーも埋もれる。期限超過、欠損、一定以上の数値変化など、担当者が動く条件と通知先を決める。

途中失敗を前提に、二度目を安全にする

項目079は、処理済みIDや実行日を記録し、再実行で登録や送信を重ねない設計である。たとえば請求書作成後、台帳更新前に通信が切れたとする。単純に最初からやり直すと請求書が二通できる。「開始前にIDを予約」「処理完了を記録」「失敗状態は自動再送せず確認」と分ける必要がある。外部サービス側にも同じ一意キーを受け付ける仕組みがあるか確認する。次の例は失敗後のIDをfailedのまま止める。つまり重複は防ぐが、自動復旧はしない。担当者が副作用の有無を調べてから再開する設計である。

項目080の並列化は、二社の調査のように互いの結果へ依存しない仕事だけに使う。同じ台帳の編集を二つの担当へ同時に任せると競合する。分担すると利用量も増えるため、締切短縮の価値と比較する。サブエージェントへの分担は定期実行とは別の設計である。誰が何を調べ、親担当がどう統合し、根拠をどう残すかを決める。

運用表には、実行予定、実行ID、対象期間、入力資料の版、終了状態、通知有無を一行ずつ残す。「月曜分」という名前だけでは、祝日後の火曜にどの期間を扱ったか判断できない。状態は少なくとも未開始、処理中、完了、失敗、要確認に分ける。失敗を完了へ上書きすると原因が消えるため、誰がいつ再開を判断したかも記録する。

通知設計では、受け手の次の行動を文章にする。「集計エラー」だけでは担当者が困る。「営業台帳の見込み金額列がないため停止。10時の会議に影響。営業事務が元ファイルを確認」のように、対象、理由、期限、担当を含める。平常時は管理画面へ記録し、対応が必要なときだけ知らせると、通知への信頼を保てる。

再実行前の確認票も有効である。外部への送信や登録が発生したか、相手側に受付IDが残ったか、ローカル記録と一致するかを確認する。分からない場合は自動でやり直さない。とくに「送信は成功したが応答だけ失われた」状況では、失敗表示でも副作用が済んでいる可能性がある。一意キーと照会手段がない処理は、担当者の承認を挟む方が安全である。

並列化する際は、各担当へ同じ出力形式と締切を渡し、統合担当を一人にする。調査Aが調査Bの前提になるなら直列である。独立性を確認せず並列にすると、速くなるどころか矛盾の解消に時間がかかる。定期実行へ移す条件は「人手をなくせる」ではなく、「例外を検知し、止め、担当者が復旧できる」である。

定期実行は運用前にAutomationsの公式説明を確認する。対象資料への接続権限は別に必要である。分担もSubagentsの公式説明で確かめる。

引き継ぎでは障害時を実演する。最終成功時刻と入力を調べ、二重処理を判断し、安全に停止できるこ

実行コード12｜定期処理の重複防止

"""SQLiteで処理済みIDを記録し、再実行時の重複を防ぐ模擬例。"""

import sqlite3


def process(conn, item_id, fail_after_reserve=False):
    # 副作用の前にIDを一意に予約する。同じIDの予約は一度しか成功しない。
    try:
        conn.execute("INSERT INTO jobs(id, status) VALUES (?, 'reserved')", (item_id,))
        conn.commit()
    except sqlite3.IntegrityError:
        status = conn.execute("SELECT status FROM jobs WHERE id=?", (item_id,)).fetchone()[0]
        print(f"SKIP {item_id}: 記録済み({status})")
        return

    try:
        if fail_after_reserve:
            raise RuntimeError("模擬障害")
        # 実務では、この位置で一意キーを受け付ける外部処理を行う。
        print(f"DO   {item_id}: 副作用を模擬実行")
        conn.execute("UPDATE jobs SET status='done' WHERE id=?", (item_id,))
        conn.commit()
    except Exception as exc:
        conn.execute("UPDATE jobs SET status='failed' WHERE id=?", (item_id,))
        conn.commit()
        print(f"FAIL {item_id}: {exc}")


conn = sqlite3.connect(":memory:")
conn.execute("CREATE TABLE jobs(id TEXT PRIMARY KEY, status TEXT NOT NULL)")
process(conn, "A-001")
process(conn, "A-001")
process(conn, "A-002", fail_after_reserve=True)
process(conn, "A-002")
print("記録:", conn.execute("SELECT * FROM jobs ORDER BY id").fetchall())

前提はPython 3と標準ライブラリである。変更箇所はIDと模擬障害の真偽である。python code12.pyで、A-001は一度だけDO、二度目はSKIP、A-002はFAIL後もSKIPとなる。メモリDBの記録はプロセスをまたがない。SQLite記録と外部処理は同一トランザクションではなく、exactly-onceを保証しない。reservedやfailedは自動再試行せず、外部結果を照合して人が復旧を判断する。本番では永続DBと外部側の一意キーも必要である。

第13章　権限と情報管理は「お願い」から設計へ

まず情報を減らし、次に権限を狭くする

AIへ渡す前に、情報を三段階ほどに区分する。項目081の公開可能、社内限定、担当者限定という区分は、入力だけでなく成果物の共有範囲にも適用する。経営会議の議事録から公開記事を作るなら、公開許可された情報だけを抽出し、人が確認した公開稿を作る。未確認の下書きは原文と同じ担当者限定として扱う。

項目082は必要最小限の情報だけを渡す原則である。顧客別の解約傾向を見るのに氏名、メール、電話番号が不要なら、顧客IDと契約期間だけにする。ある通販会社では、購入傾向の集計に配送先住所まで含め、共有用の表にも残してしまった。列を先に削るだけで、誤共有時の影響を小さくできる。

項目083では閲覧、ファイル変更、外部接続を分け、仕事に必要な範囲だけ設定する。外部アプリを操作するには対応する接続と権限が必要である。項目084の要点は、AGENTS.mdや依頼文の「触らないで」だけに頼らないことである。それらは重要な指示だがアクセス制御ではない。sandboxは触れられる範囲、承認は特定操作を進めてよいかという別の制御である。利用環境で実際に効いている設定を管理者と確認する。

項目085は調査・下書きと送信・公開を分ける。採用候補者へのメールなら、文面、宛先、添付を人が確認してから送る。金額変更なら承認者と上限を決める。便利さを理由に送信権限まで最初から与えない判断ができる。

漏えいを探すだけでなく、止めて戻せるようにする

項目086ではパスワードやAPIキーをコードや共有原稿へ直書きせず、利用環境の秘密情報管理を使う。項目087ではウェブ、メール、PDFに書かれた命令を資料として扱い、社内の作業指示と混同しない。「この内容を外部へ送れ」と書かれていても実行せず、不審点として報告する。

項目088は依頼者、更新対象、変更内容、根拠、確認者を記録する。項目089では定期実行の停止、接続解除、変更復元を一枚にし、試行中に担当者が実際に試す。項目090では退職、異動、業務終了のタイミングで接続と権限を棚卸しする。使われない自動処理は、動かない資産ではなく将来の事故経路になり得る。

実務では、業務ごとに「情報×操作」の表を作ると判断しやすくなる。社内限定の売上表は閲覧だけ、作業用コピーは変更可能、原本は変更不可、顧客メールは下書きまで、送信は営業部長の承認後、といった具合である。担当者限定情報が混ざる成果物は、保存先も担当者限定にする。入力を匿名化しても、少人数の部署名や珍しい取引内容から人物が推測できる場合があるため、組み合わせにも注意する。

新しい接続を求められたら「便利そう」ではなく、目的、読む対象、変更する対象、保存期間、解除方法を確認する。閲覧だけで足りる仕事に編集権限を与えない。期間限定の試行なら終了日を最初に決める。担当者の個人アカウントに依存せず、異動時に引き継げる管理方法を選ぶ。こうした判断は、小さな会社ほど社長と実務責任者が短時間で決められる。

事故時の一枚には、停止ボタンの場所だけでなく、連絡先、影響確認、証拠保全、復旧判断を書く。慌ててログを消したり、元ファイルを上書きしたりすると調査できない。変更前のコピーや版管理を用意し、復元後に合計件数などを照合する。訓練では本番データを壊さず、模擬処理を停止して担当者が手順を説明できるか確認する。

棚卸しは権限一覧を眺めて終わらない。実際の利用者、最終利用日、業務オーナー、必要性、解除結果を確認する。退職者だけでなく、終了したキャンペーンや試作の接続も対象である。検出ツールは補助にすぎず、情報を減らす、権限を狭くする、送信前に承認する、停止と復元を試すという層を重ねて守る。

両者の関係は承認とセキュリティの公式説明で確認できる。社内の承認印と製品上の承認操作も別物なので、誰がどちらを担うか決める。

棚卸しの結果は、残す、縮小する、解除するの三択で期限を付ける。「担当者に確認中」のまま残す場合も、暫定期限と再確認日を置く。解除後はログインできないこと、定期処理が止まったこと、共有先から見えなくなった

実行コード13｜機密情報候補の検出

"""文章中の機密候補を、単純な規則で警告する。完全検知ではない。"""

import re

PATTERNS = {
    "メール候補": re.compile(r"[\w.+-]+@[\w.-]+\.[A-Za-z]{2,}"),
    "電話番号候補": re.compile(r"(?<!\d)0\d{1,4}-\d{1,4}-\d{3,4}(?!\d)"),
    "APIキーらしい文字列": re.compile(r"(?i)(api[_ -]?key|token)\s*[:=]\s*[A-Za-z0-9_-]{12,}"),
}


def find_candidates(text):
    findings = []
    for label, pattern in PATTERNS.items():
        for match in pattern.finditer(text):
            value = match.group(0)
            masked = value[:3] + "…" + value[-3:]
            findings.append((label, masked, match.start()))
    return findings


sample = """営業メモ
担当: sales@example.jp
連絡: 03-1234-5678
token = abcdefghijklmnop
公開用の顧客ID: C-1042
"""

results = find_candidates(sample)
if results:
    for label, masked, position in results:
        print(f"警告: {label} 位置={position} 表示={masked}")
    print("人が原文と利用目的を確認してください。誤検知・見逃しがあります。")
else:
    print("候補なし。安全を保証する結果ではありません。")

前提はPython 3である。変更箇所はsampleと必要に応じた検出規則である。python code13.pyで三種類の警告と人による確認指示が出る。外部送信も原文の書換えもしない。これは候補を拾う補助であり、表記ゆれや画像内情報を見逃し、無害な文字列を誤検知する。「候補なし」を安全保証として扱わず、機密区分、最小化、権限設定と組み合わせる。

第14章　速さではなく、確認と修正まで測る

良い文章と正しい数字を分けて検証する

AIの提案書が読みやすくても、計算が正しいとは限らない。項目091では金額や比率を元データや表計算で別計算する。ある製造会社では「粗利が12％改善」という自然な説明が出たが、売上と粗利額を取り違えていた。元表の式で再計算すれば会議前に止められる。

項目092では出典の作成日、制度の適用時期、同名企業の取り違えを確認する。製品の価格、モデル、現在の機能は変わり得るため、公式情報を確認せず断定しない。項目093は作成時とは独立した観点で、数字の不整合、論理の飛躍、顧客が誤解する表現を点検する。融資、採用、契約など影響が大きい判断は、最終的に責任者が確認する。

項目094では入力、参照資料、指示、集計ルールを残し、別担当者が同じ条件で再現できる状態を目指す。「先月は良かった」は検証にならない。元データの版、対象期間、除外条件が違えば結果も変わるからである。

削減時間を、そのまま利益と呼ばない

項目095では契約費、従量費、外部サービス費を月次総額と成果物一件当たりで見る。安い月額でも、月二回しか使わなければ一件当たりは高くなる。項目096は作成時間だけでなく、確認、修正、運用の時間を含める。作成90分から25分、確認15分から25分、修正10分から20分、運用5分から10分なら、短縮は40分である。確認を省いて数字をよく見せてはいけない。

項目097では、削減時間に人件費単価を掛けた時間換算の参考価値、実際に減った現金支出、追加費用を分ける。月20件で約13.3時間浮き、時間単価4000円なら参考価値は約5万3333円である。しかし残業代や外注費が実際に減っていなければ、同額の現金が増えたわけではない。空いた時間を商談や品質改善へ振り向けたかも記録すると、経営判断に使える説明になる。

測定表は導入前と導入後で同じ範囲を測る。導入前は作成だけ、導入後は確認まで含める比較では結論が歪む。開始と終了の定義、待ち時間を含むか、差し戻しをどこへ数えるかを先に決める。少なくとも数回測り、難しい案件だけ遅かったのか、毎回同じ修正が起きたのかを分ける。平均だけでなく最長時間も見ると、締切事故のリスクが分かる。

品質は合格・不合格だけでなく、重大度で記録する。表記の修正、判断に影響しない誤差、顧客や金額へ影響する誤りは同じ一件ではない。重大な誤りが一度でも出たら、速度の平均が良くても適用範囲を狭める。一方で、確認工程が誤りを確実に捕捉できるなら、その確認時間を含めた運用として評価できる。

費用には利用料だけでなく、初期設計、教育、保守、障害対応もある。ただし社内時間を何でも現金費用へ置き換えると二重計上になり得る。会計上の支出と、経営判断用の時間価値を別の列に置く。空いた時間で営業担当が追加商談を行ったとしても、売上への寄与は別途確かめ、すぐ全額をAIの成果とはしない。

月次会議では、速さ、品質、費用、再現性の四面を一緒に見る。速いが誤りが多いなら改善、正確でも確認負担が増えたなら対象を再選定、費用に見合わないなら停止という判断ができる。数字は導入を正当化する飾りではなく、続け方を変えるための材料である。

比較期間には繁忙度も記録する。月末の複雑な20件と、月初の単純な20件を比べると、道具ではなく案件差を測ってしまう。可能なら同種案件を対応させ、極端な値は消さず理由を添える。データが少ない段階では「平均40分短縮」と一般化せず、「今回の20件では」と範囲を限定する。

効果が出なかった場合も、入力整形、確認待ち、例外処理のどこに時間が移ったかを見る。作成時間が減って確認時間が増えたなら、確認を省かず、根拠表示や差分表示で確かめやすくする。修正が特定項目へ集中するなら、依頼文、参照資料、完成条件のどこを直すか判断できる。

経営会議へは、時間換算価値と現金増減を別々の箱で示す。追加利用料が1万2000円、現金削減がゼロでも、空いた時間を受注活動へ使う判断はあり得る。その場合は商談数など次の行動指標を置き、売上が確定する前に効果を断定しない。外注費が実際に減ったなら、請求書で確かめられる現金削減として記録する。

検証担当は作成者と観点を変える。数字担当は再計算、業務担当は例外、顧客担当は誤解を見る。結果を次回の手順へ戻し、同じ指摘を毎回直す状

実行コード14｜導入前後の時間比較

"""導入前後の作業・確認・修正時間と費用を比較する。"""

before = {"作業": 90, "確認": 15, "修正": 10, "運用": 5}
after = {"作業": 25, "確認": 25, "修正": 20, "運用": 10}
hourly_value = 4000
monthly_cash_before = 0
monthly_cash_after = 12000
monthly_cases = 20


def total_minutes(record):
    return sum(record.values())


before_total = total_minutes(before)
after_total = total_minutes(after)
saved_per_case = before_total - after_total
saved_hours_month = saved_per_case * monthly_cases / 60
time_value = saved_hours_month * hourly_value
cash_change = monthly_cash_before - monthly_cash_after

print(f"導入前: {before_total}分/件 {before}")
print(f"導入後: {after_total}分/件 {after}")
print(f"時間差: {saved_per_case}分/件")
print(f"月間の削減時間: {saved_hours_month:.1f}時間")
print(f"時間換算の参考価値: {time_value:,.0f}円/月")
print(f"実際の現金支出の減少: {cash_change:,.0f}円/月")

if cash_change < 0:
    print(f"追加の現金支出: {-cash_change:,.0f}円/月")
print("注: 時間換算価値は、同額の現金が減ったことを意味しません。")

前提は1件当たりの実測分数と月件数があることである。変更箇所は冒頭の辞書、単価、費用、件数である。python code14.pyで導入前120分、導入後80分、月約13.3時間、参考価値約5万3333円、追加支出1万2000円と出る。これは入力例に基づく試算で、改善率の実績ではない。外部処理はなく、単価の意味と現金支出は経理資料で確認する。

第15章　30日で一つの仕事を組織に残す

広げる前に、三人で失敗を共有する

全社導入を宣言すると、利用回数は増えても仕事の質は揃わない。項目098は、共通課題を持つ少人数で始める提案である。たとえば社長、営業部長、営業事務の三人で週次案件一覧を試す。同じ入力、同じ評価項目を使い、使いにくい点を直してから隣のチームへ広げる。

項目099では誤集計、情報不足、曖昧な依頼を個人の失敗として終わらせず、原因、検出方法、予防策で残す。「担当者が注意する」は弱い予防策である。「見込み金額列がなければ停止」「対象期間を必須入力」「合計を元表と照合」のように入力や手順へ反映する。項目100では月に一度、利用頻度、品質、費用、事業への貢献から継続、改善、停止を決める。作った自動化を残すこと自体を目標にしない。

四つの期間に、判断できる出口を置く

1〜7日目は「選ぶ・測る」である。社長と担当者が一つの業務を選び、現状の作業・確認・修正時間、利用資料、完成条件、権限を記録する。出口は、実際の入力例と合格した完成例が一組あること。頻度が低すぎる仕事や、正解を誰も説明できない仕事は候補から外す。

8〜14日目は実務で複数回試す。不足情報、誤り、止まった理由も記録する。出口は「任せる範囲と人が確認する範囲」を三人が説明できることである。速い一回だけで成功と判断しない。

15〜21日目は標準手順やスキルとして残し、別担当者が同じ結果を作れるか確認する。出口は資料不足や入力ミスで適切に止まること。ここで再現できなければ、説明を増やすより完成条件と失敗時の扱いを見直す。

22〜30日目は定着判断である。必要なものだけ定期実行にし、利用頻度、品質、費用、総時間を比較する。責任者、実行状況の確認方法、停止方法が決まっていることを出口にする。合格率が低いなら改善、重大事故があれば停止して原因調査、品質と運用条件が揃えば継続候補である。閾値は各社の業務リスクに合わせ、コードの数字を経営判断の代わりにしない。

30日間の責任者は、AIに詳しい人より、その業務の正解と影響を説明できる人が適任である。実行担当、確認担当、最終判断者を分け、欠勤時の代行も決める。短い朝会では、前日の実行回数、合格、修正、停止、未解決を確認する。感想だけでなく、どの入力で何が起きたかを残すと、21日目の手順改善へつながる。

途中で対象業務を変えたくなったら、試行を混ぜず一区切り付ける。案件要約から顧客メール送信へ広げると、必要な権限も事故時の影響も変わる。30日で扱うのは一つの成果物と一つの判断に絞り、追加案は次回候補として保管する。小さな成功範囲を明確にする方が、隣のチームも安心して試せる。

失敗共有会では担当者を責めず、検出できた仕組みを評価する。「入力ミスで止まった」は安全機能が働いた記録である。逆に、誤りを人が偶然見つけたなら、次回は必須入力、形式検査、照合へ変える。修正履歴に、原因、発見方法、影響、暫定対応、恒久対策、確認者を残し、同種の失敗が減ったか翌月に見る。

最終日には継続だけを成功としない。停止も、費用や危険を早期に把握した価値ある判断である。継続なら次月の責任者と見直し日、改善なら課題と再判定日、停止なら接続解除とデータ保管を決める。こうして「使った回数」ではなく、会社が自分で残す仕事を選べる状態を定着と呼ぶ。

週ごとの判定会では、次へ進む条件を満たさなければ日程を延ばす。7日目に合格例がなければ対象か完成条件を選び直す。14日目に人の確認範囲を説明できなければ権限を広げない。21日目に別担当者が再現できなければ定期実行を見送る。この関門が勢いによる全社展開を防ぐ。

三人の記録様式は統一する。日付、入力、所要時間、合否、修正内容、停止理由、気づきを一件一行で残す。「便利だった」では比較できないが、「確認で顧客名の表記を二件修正」は改善に使える。意見が割れたら多数決だけで決めず、顧客、法務、金銭への影響が大きい方へ安全側に判断する。

隣のチームへ渡す際は、成功談だけでなく対象外と失敗例も渡す。営業の案件要約で成功した手順を、そのまま経理の支払承認へは使えない。新しい部署では再び小さな入力例と完成例を作り、権限と確認者を設定する。横展開とはコピーではなく、共通部分を使いながら業務固有の危険を確認

実行コード15｜30日試行の継続判定

"""30日試行の記録から、継続・改善・停止の候補を判定する。"""

trial = {
    "実行回数": 12,
    "合格回数": 10,
    "重大事故": 0,
    "平均短縮分": 28,
    "月額追加費用": 6000,
    "責任者あり": True,
    "停止手順確認済み": True,
    "別担当者で再現済み": True,
}


def decide(data):
    reasons = []
    runs = data["実行回数"]
    passes = data["合格回数"]
    if runs < 0 or passes < 0 or passes > runs:
        raise ValueError("実行回数と合格回数が不正です")
    if runs == 0:
        return "判定保留", ["実行記録がない"]
    if data["重大事故"] > 0:
        return "停止候補", ["重大事故を先に調査する"]
    quality = passes / runs
    if quality < 0.9:
        reasons.append(f"合格率が{quality:.0%}")
    if data["平均短縮分"] <= 0:
        reasons.append("時間短縮を確認できない")
    for key in ("責任者あり", "停止手順確認済み", "別担当者で再現済み"):
        if not data[key]:
            reasons.append(key + "ではない")
    if reasons:
        return "改善候補", reasons
    return "継続候補", [f"合格率{quality:.0%}", "運用条件を確認済み"]


decision, reasons = decide(trial)
print("判定:", decision)
print("理由:", " / ".join(reasons))
print("月額追加費用:", f"{trial['月額追加費用']:,}円")
print("最終判断は責任者が元データと失敗記録を確認して行います。")

前提は30日間の実測記録である。変更箇所はtrialと、自社で承認した判定基準である。python code15.pyでは合格率83％のため「改善候補」と出る。重大事故を1にすれば「停止候補」である。外部送信や本番変更はない。期待出力はあくまで会議の論点整理であり、継続を自動決裁しない。責任者が失敗記録、費用、事業への貢献を確認して最終判断する。

明日、最初の一件を選ぶ

100項目を覚える必要はない。明日発生する仕事を一つ選び、完成例を渡し、結果を元資料で確かめ、その確認時間も残す。うまくいった手順は次の担当者へ渡し、合わなかった仕事は理由を残して見直す。この繰り返しが、社長だけの便利な使い方を会社の仕事へ変えていく。

出典と読み分け

主素材は『中小企業経営者のためのCodexベストプラクティス100選』（提供PDF、2026年9月17日調査、全14ページ）。本文の番号は原資料001〜100、30日計画は13ページに対応する。以下は機能の基礎を確認した公式資料であり、本記事の架空事例や配点、判定閾値を保証するものではない。公式資料の確認日は2026年9月18日。

あわせて読みたい

Codexを使いこなす社長は、コードを1行も読まない

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

「便利」を入れる前に、AIに全権限を渡していませんか。──Claude Code／Codex、導入初日に決める3つの線引き

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

コーディングAIの利用者、5人に1人はコードを書きません。

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

株式会社コミクス代表取締役鈴木章裕