研修を公開できる会社と、できない会社を分けているもの
ある会社が新卒向けのAI研修を全編公開して話題になった。すごいで終わらせずに「なぜこの会社は出せるのか」を分解すると、公開の可否を決めているのは太っ腹さではなく、育て方が目次の立つ構造になっているかどうかだった。自社の育成を同じ物差しで点検する3つの問いを置く。
出せないのは機密だからではなく、教材の形になっていないから。
Currents編集部
Currents Journal
個人の判断力を、
組織の力に変える。
AIツールの紹介ではなく、AIに何を任せ、何を仕組みに落とすかの「線引き」を、自社の現場で試してから記録する設計原則のログ。
ここは、AIや自動化を「すごい技術」として眺める場所ではありません。予約対応、記事公開、SNS運用、社内ナレッジ整理など、日々の業務手順を型にして自社運用する現場から、AI時代の業務設計——どこまで任せるか、何を仕組みに落とすか、後から変えにくい前提は何か——を、事例・設計判断・運用上の注意に分けて記録します。
最新記事
そのほかの記事
BizOps
BizOpsは何屋さんか — 4つ並べたくなった時点で、問いが2つ混ざっている
業務改善の部門はミッションを聞かれると答えに詰まる。実態が「何でもやる」だからだと思われがちだが、本当の理由は「何屋か」と「何に効かせるか」という別々の問いを1つに混ぜているからだ。分ける方法と、犠牲列を書かないと営業サポート屋に転落する話。
2026-07-29
AIと業務設計
AIが速く作るほど、「戻せる」が効いてくる — AI時代にGitが不要にならない理由
AIがコードを書く時代に、Gitはプログラマの道具から「AIと働くための台帳」に意味が変わった。戻せる・壊れる範囲を限る・承認の場所を作る、の3つの構造がAIへの任せ方をどう変えるか、自社の失敗込みで。
2026-07-28
AIと業務設計
「AI活用法50選」をほぼ実装済みの会社で、それでも事故は起きた
22万回表示された「Claude Code活用法50選」を自社の運用と突き合わせたら、9割はすでに実装済みだった。それでも事故は起きている。経営が予算をつけるべきは51個目の活用法ではなく、事故を組織の学習に変えるループだという話。
2026-07-18
AIと業務設計
形式だけの承認は、ノールックのハンコと同じ——だから公開ボタンをやめた
ブログ運用をほぼ全自動化し、「それでも公開ボタンだけは人が押す」という原則の記事を書いたら、押す本人に「正直めんどくさい」と言われた。押す義務を止める権利に置き換えるまでの、線引きのやり直しの記録。
2026-07-16
AIと業務設計
寝ている間にAIに仕事をさせる前に決めたこと
AIが夜中に勝手に動いてくれたら楽だ。ただし、朝起きたら取り返しのつかないことが終わっていた、という事故は絶対に避けたい。夜間の無人自走ランナーを設計するとき、「何をやらせるか」ではなく「何をやらせないか」から決めた記録。
2026-07-13
AIと業務設計
「動いた」をどこまで信じるか——AIで作ったLINE予約のテスト設計
会話が返ってくる、偽物のAPIで通る、台帳に書ける。同じ「動いた」でも、保証している範囲はまったく違う。自社で運営するうどんカフェのLINE予約テストを、部品・結合・本番手前・運用監視の4層に分けて、どの層で何を保証するかを言葉にした。
2026-07-12
BizOps
型を残して、抜ける — 属人化した現場に“触媒”として入るという仕事
属人化の解は、代わりの一人を採ることでも、業務を抱え込むことでもない。判断基準を読める型に変え、いなくても回る状態にして抜ける。ある企業の業務改革を、代行ではなく「触媒」として進めた記録から。
2026-07-12
AIと業務設計
AIへの指示書に書いても、AIは確率でしか守ってくれない — 守らせたいルールは仕組みに落とす
AIへの指示書は「お願い」であって「強制」ではない。守れないと事故になるルールだけを、CIやフックという機械に移して確定的に効かせた設計判断の記録。ただし機械で「落とす」のは確定NGだけに絞り、グレーは指摘で返すに留めた理由まで。
2026-07-11
AIと業務設計
「AIでPMOを手伝う」と「AIがPMOになる」のあいだ
大手向け「AIでPMOを手伝う」設計と、中小企業向け「AIがPMOになる」設計の違い。97の業務手順を型にしてきた現場から見えた3つの要件。
2026-07-05
AIと業務設計
AIで作る前に、データ設計だけは決めておく
AIで実装が速くなった今、課題定義の甘さはそのままデータ設計に埋まる。最初に決めないまま走ると、あとから権限、履歴、移行でやり直しが増える。
2026-06-30
AIと知識管理
読んだ記事を見返さない問題を、Claude Codeに整理してもらう
LLM-Wikiは、読んだ記事やメモをAIが継続的にWikiへ統合していく考え方。Claude CodeとObsidianを使うと、人間は読む係、AIは整理する係という分業を作れる。
2026-06-30
AIと業務設計
社内業務にAIを入れる前に、まず決めること
社内業務にAIを入れるとき、議事録や課題表の自動化だけでは成果につながりにくい。大事なのは、業務、データ、権限、検証、人間の判断点を先に設計し、AIが安全に働けるループを作ること。
2026-06-30
AI開発と業務設計
日付入力ひとつに、専用部品はいらない
AIにコードを書かせると、日付入力ひとつにも専用コンポーネントが生まれることがある。Ponytailの考え方を手がかりに、AI開発で作りすぎと削りすぎを分けるレビュー観点を整理する。
2026-06-30
AIと業務設計
AIエージェントの統制をどう考えるか
AIエージェントに業務を任せるなら、実在性、網羅性、正確性、権限、期間、証跡をどう残すかまで設計する必要がある。人が処理する前提で作った統制を、AIの処理にも届く形に直す話。
2026-06-30
AIと業務設計
AIに仕事を任せるとき、最後に詰まるのは「権限」だった
AIに作業を任せると、調査やコード変更はかなり進む。でも、最後に止まるのは技術力ではなく、アカウント権限や本人確認だったりする。GCPとGoogle Analyticsの小さなつまずきから、AI社員に任せる仕事の境界を考えた。
2026-06-29
AIと業務設計
「どうやるか」はもう設計の中心じゃない — AI時代に残る仕事の話
AIがUIも手順も生成できるようになった今、設計の勝負は「How」から「What / Why」に移った。組織に必要なのは作業遂行力ではなく、「こうありたい」を言語化する力。
2026-06-28
AIと業務設計
「まず整理してから」で止まる現場がある
属人知を文書化してから標準化し、それからAI化する。この順序だけだと、整理する余裕のない現場は止まる。使いながら型を作るための話。
2026-06-28
AIと業務設計
「あの人が休むと止まる」をなくす — 中小企業がAIで“初動”だけ先に手放す順序
属人化は気合でも採用でも直らない。判断が言語化されていないという構造の問題だ。まず手をつけるべきは、最終判断ではなく入口の振り分け——一次切り分け（トリアージ）である。
2026-06-27
BizOps
代行と内製化、どちらが得か — 6ヶ月で逆転する損益分岐の読み方
BPOで回すコストと、自社で仕組みを持つコスト。判断を感覚でなく数字で。どこで線が引かれ、いつ逆転するかを置いて考える。
2026-06-20
AIと業務設計
確定ボタンまでAIに渡さない
AIは判断と読み取りまで。確定・送信・支払いは人と決定論に残す。被害を出さずに自動化するための、境界とガードの実装。
2026-06-18