この記事でわかること
- AI活用の差は「どのAIを使うか」ではなく、単発で聞いているか、業務の工程として常設しているかで開く。
- 議事録整形・月次レポート生成のような定型業務は、作業単位ではなく工程単位で渡すと自律的に回りはじめる。自社での実装手順を公開します。
- ただしAIの自動化は「作った時点」ではなく「運用」で壊れます。実際に自社で起きた障害と、人間が握り続けるべき判断のゲートを解説します。
「AIに聞く」と「AIが動く」は別物
生成AIの使い方として一般的なのは、文章を書かせる、要約させる、調べさせる、という単発の依頼です。これ自体は有効で、私たちも毎日使っています。
ただ、この使い方には天井があります。毎回ゼロから説明し直す必要があるからです。会社の前提、過去の経緯、書式のルール、判断基準。これらを都度プロンプトに書いていると、AIに渡す準備のほうが作業本体より重くなります。結果、「AIを使うと逆に遅い業務」が生まれ、定着せずに終わります。
差がつくのは、AIを業務の中に常設された工程にしたときです。前提が置かれた場所を持ち、決まった手順で、決まった成果物を出す。人間は起動と最終判断だけを担う。同じモデルを使っていても、この構造の有無で半年後の差は大きくなります。
そして、この転換に必要なのは高度なプロンプト技術ではありません。工程の切り分け方です。
作業単位で渡すと失敗し、工程単位で渡すと回る
多くの自動化が定着しない原因は、渡す単位を間違えていることにあります。
「議事録を整形して」は作業単位の依頼です。この粒度では、毎回ファイルの場所を指定し、書式を説明し、出力先を指示することになります。人間の手間が減りません。
一方、工程単位とは次のような渡し方です。
録音の書き起こしを受け取る → カレンダーと突き合わせて会議を特定する → 発言者を推定する → 決定事項・宿題・未決に分類する → 命名規則どおりのファイル名で所定のフォルダに格納する → 既存文書との差分を検出する
一連の流れをまとめて定義し、名前をつけて呼び出せる状態にする。 これがAIを工程として持つということです。 私たちはこれをClaude Codeの「スキル」として実装しています（Claude Code公式ドキュメント）。一度定義すれば、次からは呼び出すだけで同じ品質の出力が返ります。
判断の目安はシンプルです。その業務を新人に引き継ぐとき、口頭で済むなら作業、手順書が要るなら工程。 手順書が要る業務こそ、AIに常設で持たせる価値があります。
自社で常設している3つの工程
実際に運用している例を挙げます。いずれも、以前は人がやっていた定型業務です。
1. 会議の録音から構造化議事録まで
ICレコーダーの書き起こしをクラウド経由で受け取り、カレンダーの予定と突き合わせて会議を特定し、議事録を生成する工程です。
ある支援先の全体会議（約90分）では、書き起こしから決定事項21件・宿題10件・未決事項8件を分類した議事録が生成されました。発言者は「誰がどの領域の話をしているか」から推定し、推定の根拠と確度を併記させています。断定させないことがポイントです。
書き起こしの誤変換（社名や人名が音の近い別語になる）は避けられないため、読み替え表を議事録の冒頭に出力させる設計にしました。誤変換をなかったことにせず、可視化して残す。これで後から読む人が誤解しません。
2. カレンダーから月次稼働レポートのドラフト生成
月次の業務報告書を、カレンダーの実績から集計してドラフトを作る工程です。所定のフォーマットのファイルとして出力されます。
ここで重要なのは、ドラフトまでしか作らせていないことです。カレンダーに乗らない稼働（移動中の思考、細切れの対応）はどうしても発生するため、時間の最終調整は人間が行います。この線引きを曖昧にすると、実態と合わない報告書が自動で量産されます。
3. セッションの引き継ぎ生成
一日の作業終了時に、その日やったこと・未完了のタスク・次に着手すべき点を引き継ぎ文書として自動生成し、翌日の開始時に読み込ませる工程です。
これは地味ですが、効果が最も安定しています。AIに毎回ゼロから説明し直す状態から抜けられるのが理由です。前述した「準備のほうが重い」問題を、構造で解消しています。
工程を渡すための5ステップ
自社で回してきた手順を一般化すると、次の5段階になります。
- 工程を棚卸しする：月1回以上発生し、毎回ほぼ同じ手順を踏む業務を書き出す。頻度が低い業務は自動化しても元が取れません。
- 入口と出口を固定する：どこにファイルが置かれたら起動し、どこに何という名前で出力するかを先に決める。ここが曖昧なままだと、実行のたびに人間が指示することになります。
- 手順書として書き下す：新人に渡す手順書と同じ粒度で、判断基準（何を決定事項とみなすか等）まで言語化する。
- 名前をつけて常設する：呼び出し可能な単位として保存する。ここで初めて「毎回説明する」状態から抜けます。
- 人間のゲートを1箇所残す：出力をそのまま外部に出さず、人が確認する地点を設計に組み込む。
とりわけ重要なのは5です。次章で詳しく述べます。
よくある落とし穴
落とし穴1：AIの自動化は「運用」で壊れる
作った時点では動いていた仕組みが、運用の中で静かに壊れることがあります。
自社で実際に起きた例です。AIを常時起動しておくための土台（作業用サーバー上のセッション管理）に不具合があり、AI本体が終了しても入れ物だけが残る状態になっていました。結果、起動コマンドを打っても中身の無い箱に接続され続けます。
障害の記録を見ると、直近の操作履歴40行のうち、同じ起動コマンドが11回、AIに届かなかった指示が5回残っていました。作業そのものではなく、作業を始めるための復旧に時間が溶けていたことになります。
原因は2つでした。①終了したセッションを「生きている」と誤判定していたこと。②AIの起動完了を1秒の固定待ちで判断しており、外部サービス連携（カレンダー・スプレッドシート・チャットなど4系統）の読み込みに間に合っていなかったこと。いずれもAIの賢さとは無関係な、運用設計の不備です。
自動化を設計するときは、成功時の動きだけでなく、落ちたときにどう検知し、どう復旧するかまで含めて設計してください。ここを飛ばした仕組みは、忙しい時期ほど止まりやすくなります。
落とし穴2：出力の見た目が整っているほど検算されなくなる
AIの出力は体裁が整っているため、内容の誤りが見逃されやすくなります。特に数値と固有名詞は、書き起こしの誤変換や集計の取り違えが起きても、文章としては自然に読めてしまいます。前述の「読み替え表を冒頭に出す」設計は、この対策でもあります。
落とし穴3：自動化と同時に防御の設計が抜ける
工程を増やすほど、AIが触れる情報の範囲は広がります。顧客情報、契約金額、認証情報。何をAIに渡さないかのルールを、自動化と同じタイミングで決めてください。自社では、機密情報の扱いと外部送信の禁止事項を土台の設定ファイルに明文化し、認証情報は設定に直書きせず外部の保管庫から注入する運用にしています。
アクセルだけでなくブレーキを設計して、初めて安全に速く走れます。
実証：この記事自体が工程の産物です
前述の3工程は、いずれも現在稼働中の仕組みです。この記事の執筆も、既存記事の重複チェック・書式規約の確認・下書き生成までを工程として通したうえで、内容の判断と加筆を人間が行っています。
自社での運用から見えているのは、次の点です。
- 定着するのは手順書が書ける業務に限られる。属人的な判断が中心の業務は、工程化しても結局人が全部書き直すことになります。
- 効果が最も安定するのは、派手な生成業務ではなく引き継ぎ・記録・集計といった地味な工程。理由は、毎回の前提説明コストが消えるからです。
- 障害は起きるものとして設計する。復旧設計のない自動化は、一時的な生産性向上と引き換えに、忙しい時期の停止リスクを買っているのと同じです。
AIを部分的に導入して満足するのではなく、集客から納品、記録、改善までを一本の線でつなぐ。この構造をどこから作るかは、中小企業のAI活用ロードマップで解説した3つの判断軸から決めるのが近道です。
FAQ
Q. Claude Codeはエンジニア向けのツールではないのですか？
A. 元々は開発者向けですが、実際の用途はコードに限りません。ファイルの読み書き、外部サービスとの連携、決まった手順の反復実行ができるため、議事録・レポート・資料作成といった事務工程にも使えます。重要なのはプログラミングの知識よりも、業務の手順を言語化できるかです。手順書が書ける人であれば扱えます。
Q. 工程を作るのにどれくらいの時間がかかりますか？
A. 自社の例では、1つの工程を定義するのに数時間から半日程度です。ただし初回は想定外の入力が出るため、2〜3回運用して手順を修正する前提で見てください。1回しか使わない業務であれば、工程化せず単発で依頼したほうが早いです。
Q. AIに任せた業務の品質はどう担保していますか？
A. 出力をそのまま外部に出さず、人間が確認する地点を1箇所残しています。たとえば月次レポートは「ドラフト生成まで」と決め、実態との突き合わせは人が行います。また、推定を含む出力には根拠と確度を併記させ、断定させない設計にしています。判断の責任は人間側に残す、という線引きです。
まとめ
- AI活用の差は、モデルの選択よりも単発で聞いているか、工程として常設しているかで開く。毎回説明し直す状態が続く限り、準備コストが効果を打ち消します。
- 渡す単位は作業ではなく工程。「新人への引き継ぎに手順書が要る業務」が、常設に向く目安です。入口と出口を先に固定してください。
- 自動化は作った時点ではなく運用で壊れます。復旧の設計と、人間が握るゲートを1箇所——この2つを含めて初めて、業務に組み込めます。
関連記事
- 中小企業のAI活用ロードマップ：導入前に決める3つの判断軸
- AIが正論を量産する時代に、PMの価値が上がる理由：「責任を引き受ける力」とは何か
- エンジニアと話が噛み合わないのはなぜ？ビジネス側が会話を前に進める4つの分解
次のステップ
「どの業務から自動化すべきか分からない」「導入したが定着しなかった」という段階でしたら、 まず現状の棚卸しから。無料の「AIに出てこない会社チェック」（アペアル）でご一緒できます。