Claudeで新入社員のIT準備チェックリストを自動生成する方法

要点： Claudeは職務定義、権限一覧、市場ごとの要件を数秒で新入社員向けIT準備チェックリストに変え、どれかが変わるたびに作り直せます。できないのは、アカウントを作ること、アクセスを承認すること、端末を登録すること——それはID基盤と承認フロー、そしてIntuneやApple Business Managerの仕事です。チェックリストは自動化ではなく仕様書として使ってください。

二十人以上を採用したことのある会社なら、どこかに新入社員向けのITチェックリストがあります。たいていは二年前に辞めた誰かが書いた文書で、メールアカウント、ノートPC、昨春に置き換えられたVPNクライアント、そして末尾近くに「関連グループに追加」の一行が並んでいます。誰も所有せず、誰も版を管理せず、そして何か月ぶりかに開かれるのは、新しい人が受付に立っている月曜の朝です。

面白いのは、チェックリスト自体は本当の問題ではないという点です。多くの会社は新入社員に何が必要かを大まかには知っています。足りないのは、その知識を十数の職務、三つの国、四半期ごとに変わるアプリ群にまたがって最新に保ち、必要なときに、その人に正しい版を出す手段です。これは「生成」の問題であり、言語モデルが得意とすることそのものです。

入社チェックリストが必ず古びる理由

職務ではなくツールを記述している。 「CRMをインストール」と書かれたリストは、CRMが一つで全員が同じ使い方をしていた時代のものです。営業、サポート、経理が同じシステムに異なる権限を必要とした瞬間、ツール型のリストは本当に重要な問い——この人は何ができるべきか——に答えなくなります。

一度書かれたきり、版が管理されない。 シングルサインオンの導入、経費システムの刷新、置き換わったエンドポイント保護エージェント。そのどれもが「正解」を変えたのに、どれ一つとして文書の更新を引き起こしませんでした。新入社員が三日目になっても明らかな権限を持てずにいて、ようやく気づかれます。

市場が一つだと決めつけている。 シンガポール拠点を前提に組まれたリストは、上海では静かに機能しなくなります。調達リードタイムも、ネットワークの到達性も、適用される個人情報保護の枠組みも違うからです。多くのチームは、本国以外で初めて受け入れをするときに、最悪の形でこれを知ります。

引き渡しで終わっている。 ほとんどのリストはノートPCを渡した時点で終わります。九十日後に試用期間が終わり権限を見直すべきことには触れず、逆のプロセスには一言もありません。

所有者がいない。 入社対応は人事とIT と採用マネージャーの間にあり、実際には「最も断りにくい人」のところに落ちます。維持することが誰の目標にも入っていないので、文書は劣化します。

職務を理解するチェックリスト生成の仕組みを作る

成立させる転換は小さいけれど本質的です。チェックリストを保守するのをやめ、チェックリストの導出元となる入力のほうを保守する。リスト自体は必要なときに作り直す使い捨ての出力になります。

Claudeに与えるべき入力

役に立つ生成の仕組みに必要なものは六つで、出力の質はそれらをどれだけ正直に書き出せたかでほぼ決まります。

職務を「何をするか」で記述する。 肩書ではなく、触れるシステムと下す判断です。「顧客の決済データを扱う」という一文は、肩書が決して伝えない情報をモデルに与えます。

法人と市場。 どの法人が雇用し、どのオフィスに座り、そのデータと端末にどの国の規則が適用されるか。この一項目こそが、一枚の汎用リストを本当に別物の複数のリストに変えます。

端末の標準。 この職務にどのハードウェアを渡すか、誰が供給するか、現地調達に何日かかるか、そして会社所有か、管理下に置く個人所有端末か。最後の区別は、その後のほぼすべての手順を変えます。

権限の対応表。 どのグループ、ライセンス、アプリケーションロールがどの職能に対応するか。これはたいてい誰かの頭の中か表計算の中にあります。書き出すことが、この取り組み全体で最も価値の高い一時間です。

承認のルール。 自動で付与してよいもの、上長が要るもの、データ責任者が要るもの。モデルはこれらに印を付けるだけで、判断してはいけません。

タイムライン。 初日までに成立していなければならないこと、初日に起きること、三十日目と九十日目の節目。

実務上は、毎回の会話に貼り付けるのではなく、小さな参照文書群として保持してください。ClaudeのProjects機能はまさにこのためのもので、そのプロジェクト内のすべての会話から見える永続的な文脈になります。職務マトリクスと権限対応表が一か所に住み、更新も一度で済みます。利用できる機能は消費者向け製品、チームプラン、APIで異なるため、現行のAnthropicのドキュメントで確認してください。

人が実際に従う出力フォーマット

チェックリストはシステム別ではなく担当者別にまとめさせます。人事は人事の分、ITはITの分、採用マネージャーは自分の分。各ブロックをそのまま別の人へ渡せて、編集が要りません。ブロック内は重要度ではなく期限順に並べます。作業する人が知りたいのは「何が初日を止めるか」であって、「概念上何が最も重要か」ではありません。

各行に四つの項目を必須にします。担当者、システム、先に完了していなければならない前提、そして観測可能な完了条件です。「メールを用意する」は項目になりません。「SGテナントにメールボックス作成、ライセンス割当済み、テスト送信受信確認——IT担当、人事レコード完了が前提」なら項目です。見れば起きたかどうかが分かるからです。

出力を別の場所へ流したいときは、機械可読な形式を明示的に指定します。Markdownは多くの社内Wikiにきれいに貼れ、CSVはチケットシステムやプロジェクトツールに取り込めます。肝心なのは、プロンプトで形式を固定し、それを変えないこと。そうすれば先月版との差分が取れ、変化が目に見えます。

最後に、不確かな点は埋めずに明示するようモデルに指示してください。確信が持てない項目は、担当者名を宛先にした未解決の問いとして現れるべきです。承認ステップを静かに創作する生成リストは、分からないと認めるリストよりも悪いものです。

実例——シンガポールの営業職と上海のエンジニア

二人、同じ会社、同じ入社日。最初の三行を過ぎると、共通点はほとんどありません。

シンガポールの営業職には会社支給のWindowsノートPCが要ります。現地在庫があり、事前登録して発送すれば初回サインインで自ら構成されます。IDは単純で、法人テナントのアカウント、標準的な生産性スイートを付与するグループ、そして全体参照ではなく担当テリトリーに限定したCRMロール。顧客の連絡先データを扱うため、個人データ保護法の研修は歓迎メールの一行ではなく、完了記録の残る正式な項目としてリストに載せるべきです。携帯回線は現地法人の契約。初日から使える理由は、この経路に長いリードタイムが一つもないからです。

上海のエンジニアのリストは、ほぼ即座に分岐します。端末調達は独自のリードタイムを持つ現地プロセスなので、起点の日付が数週間前倒しになります。ネットワーク接続はチェックボックスではなく設計課題です。中国本土のオフィスから国外の協働サービスへの到達性は実際に変動するため、前提にせず検証が要ります。適用される枠組みは個人情報保護法で、必要な研修も、会社が示せなければならない証跡も変わります。社内コミュニケーションが会社の他の部分とは別のプラットフォームで動いている可能性があり、それはアカウントが一つ増え、退職処理も一つ増えることを意味します。そしてこのエンジニアには本番環境へのアクセスが必要です——どちらのリストでも、決して自動付与してはならない項目です。

この演習の要点は「モデルがこれらの違いを知っている」ことではありません。知っているのは、あなたが法人と市場の入力にそれを書いたからです。要点は、その入力さえあれば、どちらの人向けにも正しいリストを作る費用がほぼゼロになり、前提が変わっても両方が正しいまま保たれることです。

AI生成のチェックリスト vs 固定テンプレート vs 自動プロビジョニング

• 初期の手間 — 固定テンプレートは最初の一人では勝ち、その後はずっと負けます。生成方式の費用は、権限対応表を書き出す半日分。自動プロビジョニングは予算の付く、数週間規模のプロジェクトです。
• 半年後の正確さ — 生成方式が明確に勝ちます。テンプレートは書いた日だけ正確で、あとは静かに腐ります。生成の仕組みが古びる度合いは入力次第で、その入力は実際に誰かが更新できる程度に小さいものです。
• 例外的な職務への対応 — 生成方式の圧勝です。権限を絞った業務委託、再雇用者、社員が一人しかいない市場のカントリーマネージャー。まさにテンプレートが扱えず、ルール型のプロビジョニングでは変更申請が要る場面です。
• 初日のスピード — 自動プロビジョニングの勝ちで、しかも差は大きい。チェックリストは人に何をすべきか伝えるだけ、ゼロタッチ登録はそれを実行します。人数が増えるほど効いてくる差です。
• 監査可能性 — 自動プロビジョニングが最も強く、生成方式が次点。プロビジョニング基盤はログを残します。生成されたリストは日付入りの成果物を残します。九人が編集したWikiページが残すのは議論です。
• 間違えたときの代償 — 三つの中で、生成方式は間違えても最も安全です。行動の前に人が読むからです。権限を与えすぎる自動プロビジョニングの規則は、静かに、規模を伴って間違えます。だからこそ、この下で述べる承認の関門が自動化そのものより重要になります。

正直な結論はこうです。三つは競合ではありません。生成されたチェックリストが仕様で、自動プロビジョニングが実装です。権限対応表を書かないまま自動化へ飛ぶ会社は、たいてい誰も合意していないアクセス判断を自動化することになります。

AIにできない部分——承認、端末登録、そしてリスクの大きい後半

承認は手順ではなく統制です。 顧客データ、財務システム、本番インフラへのアクセスを与える項目なら、名前のある人が承認し、その承認が記録されなければなりません。モデルはどの項目に承認が要り、誰が与えるべきかを示すことはできます。決して判断そのものになってはならず、生成されたチェックリストをアクセスを実際に付与する仕組みへ直結させてはいけません。

本当の自動化は端末登録にあります。 Windows Autopilotは端末をテナントに登録し、初回サインインしたユーザーへ構成、ポリシー、アプリケーションを届けます。ITが実機に触れる必要はありません。Apple Business Managerの自動デバイス登録はMac、iPhone、iPadで同等のことを行い、Android EnterpriseはAndroid機向けのゼロタッチ経路を提供します。いずれも開封前に端末が登録されていること——通常は販売店経由か、ハードウェア識別子による——が前提で、だからこそ調達の話は入社日の数週間前にチェックリストへ載るべきなのです。要件はプラットフォームごとに異なり時期によって変わるため、設計の前に各社の最新ドキュメントで確認してください。

真実の源はID基盤であって文書ではありません。 「営業グループに追加」と書かれた項目は、ディレクトリがすでに知っている状態を記述しているにすぎません。権限の判断を職務ベースのグループへ寄せるほど、チェックリストが背負うものは減り、アクセスは「記録された」ではなく「正しい」状態に近づきます。

退職処理はリスクの大きい後半なのに、関心はごく一部しか向きません。 入社項目の漏れは初日の不便を生みます。退職項目の漏れは、すでに在籍していない人の生きたアカウントを生み、それは何年も残り得ます。同じ入力から、同じタイミングで退職チェックリストも生成し、入社用と一緒に保管してください。モデルは一つの職務記述から両方を出せます。「退職リストがない」という言い訳はそこで消えます。

正しく進めるために——ID、端末登録、ITに任せる範囲

内容が事務的に見えるせいで見落とされがちな、データの論点がこの下にあります。職務を抽象的に記述するプロンプトは無害です。個人名、入社日、給与レンジ、私的な連絡先を含むプロンプトは、個人データを伴う処理活動であり、適用される枠組み——香港のPDPO、シンガポールのPDPA、中国の個人情報保護法——の下に入ります。実務上の規則は単純です。人ではなく職務からチェックリストを生成する。名前入りの版が要るなら、生成済みのテンプレートに手元で名前を差し込めばよく、その人の情報をモデルへ送る必要はまったくありません。消費者向け製品ではなくAPIを使うなら、契約に適用されるデータ取り扱い条件を確認してください。同じではありません。

もう半分は、チェックリストが指し示す先です。ゼロタッチ登録、グループベースの権限付与、端末コンプライアンスの基準線——これらが生成されたリストを実際の業務フローに変えるものであり、正しく整えるのはプロンプトではなく構築作業です。BrocentのMDM・BYOD管理はまさにその層を扱います。登録プロファイル、コンプライアンスポリシー、そして会社所有端末と管理下の個人端末の違い。AI+サポートはプロンプト、参照文書、レビュー工程の設計を支援し、出力を速いだけでなく信頼できるものにします。管理型ITサポートは、定義された入社・異動・退職のプロセスそのものを運用します。元になる業務がまだどこにも文書化されていないなら、ChatGPTとNotionでSOPを自動生成するの記事が正しい第一歩です。文書のない業務からチェックリストを生成しても、自信ありげな推測が出てくるだけだからです。Brocentは2007年の北京での創業以来アジアで管理型ITを提供しており、本社はシンガポール、2016年から香港オフィスを構えています。

よくある質問

これは実際にアカウントを作ってくれますか？

いいえ、作るべきでもありません。モデルが出すのは仕様です。何が存在すべきか、各項目の担当は誰か、「完了」がどう見えるか。アカウント作成、ライセンス割当、グループ付与はID基盤の中で、できれば職務ベースのグループ経由で行われるべきです。言語モデルをアカウント作成APIへ直結することは技術的には可能ですが、魅力的に見える理由そのものが悪手の理由です。間違いに気づいたはずの人間を取り除いてしまいます。

職務ごとの権限を正しく保つには？

権限対応表を維持することです。本気で労力をかける価値のある唯一の成果物がこれです。どの職能がどのグループ、ライセンス、アプリケーションロールに対応するかを書き出し、システムの追加や置き換えのたびに見直し、チェックリストの生成元の入力として扱います。すでに職務ベースのグループでアクセスを与えているなら、対応表はほぼ既存のグループの記述になります。ついでに、いくつかのグループが誰の意図よりも広い権限を持っていたことに気づく良い機会にもなります。

退職処理はどうしますか。リスクの大きい後半では？

そのとおりで、しかもたいてい後回しにされます。入社チェックリストと同時に、同じ職務記述から退職チェックリストを生成し、一緒に保管してください。削除ではなくアカウントの無効化、セッションとトークンの失効、端末の回収と消去、メールボックスの委任、そして一つの拠点にしか存在しない市場固有のシステム。設計で防ぐべき失敗は、主アカウントの無効化忘れではなく、まだつながっていることを誰も覚えていなかった外部ツールのほうです。

市場ごとの端末要件やコンプライアンス要件に対応できますか？

あなたが教えた範囲でのみ対応できます。モデルは主要な規制の一般知識は持っていますが、あなたの法人構成も、現地調達の実情も、どのシステムがどの拠点から到達できるかも知りません。それらを市場の入力に書き、最新に保ち、各項目がどの市場ルールから導かれたかを出力に明示させてください。誤った前提が埋もれず、目に見えるようになります。

Intuneでなければ駄目ですか。他のMDMでもよいですか？

自社の端末構成でゼロタッチ登録に対応できる現代的なMDMなら何でも構いません。すでにMicrosoft 365を使っているならIntuneが自然です。ID、端末、アプリケーションの層が同じ基盤になるからです。重要なのは製品ではなく能力です。出荷前に登録されていること、初回サインインで構成が適用されること、そしてアクセスポリシーが本当に依拠できるコンプライアンス基準線があること。

職務マトリクスはどこに置くべきですか？

版が管理され、読みやすく、名前のある所有者がいる場所です。リポジトリ、履歴が本当に残るWikiページ、バージョン管理された文書ライブラリ、いずれも機能します。機能しないのは、所有者のいない共有ドライブ上の表計算です。この方式の価値はすべて入力が最新であることに乗っているので、誰も保守しない入力は、置き換えたはずのテンプレートより速く間違ったものになります。

まずどこから

最も頻繁に採用する職務を一つ選び、六つの入力——職務、法人、端末、権限、承認、タイムライン——を書き出してください。投資はそれだけです。チェックリストを生成し、その職務で直近に受け入れた人に実際何が起きたかと一行ずつ突き合わせ、両方向のずれに注目します。モデルが漏らしたものと、実際の運用がやっているのに誰も書き残していなかったもの。たいてい後者のほうが興味深いリストになります。入力が整ったら、他の何よりも先に、同じ記述から退職チェックリストを生成してください。あとで持っていてよかったと思うのはそちらです。チェックリストと端末登録とアクセス設計をまとめて整えたい場合は、お問い合わせください。