開発チームから全社へ。アトラスがClaudeを4ヶ月で全社導入するまでにやったこと
目次
はじめに
こんにちは。今年からCTOを務めている浜野です。
AIツールを全社で導入する会社が増えていますね。『AIツールを全社に広めたいけれど、セキュリティ統制と利用促進をどう両立させればいいか分からない』——情報システムやAI推進を担当されている方なら、一度はこの悩みにぶつかったことがあるのではないでしょうか。
アトラスでは2026年2月末にClaudeのTeamプランを契約し、3月にシステム開発グループの一部チームから利用を始め、6月までに非エンジニアを含む全社へ展開しました。エンジニアは開発支援ツールのClaude Codeを、非エンジニアはデスクトップアプリのClaude Coworkを中心に利用しています。この記事では、その4ヶ月で準備したことと、実際につまずいたポイントをすべて紹介します。
アトラスは学術情報サービスを提供する会社で、学会の会員情報に加え、学術大会で発表される前の未公開の研究情報を預かる立場にあります。未公開の研究情報は、漏えいすれば特許出願（新規性）にも影響しうるため、アトラスでは機密情報としてとくに注意して扱っています。だからこそ「AIは便利だからとりあえずClaudeのアカウントを配ろう」ではなく、安全に使える仕組みを先に作ることを重視しました。
導入の全体像：4ヶ月のタイムライン
| 時期 | 対応内容 |
|---|---|
| 2026年2月末 | Claude Teamプラン契約、組織設定の確認 |
| 2026年2月末〜3月 | システム開発グループ向けにClaude Codeの利用手順・ルールを整備し、一部チームで利用開始 |
| 2026年3月中旬〜5月 | 各グループのマネージャー・リーダーによる先行利用と活用準備 |
| 2026年4〜5月 | 非エンジニアを含む全社展開の準備（全社共通ルール、Claude Cowork導入手順書、組織設定によるガードレール） |
| 2026年5〜6月 | 全社展開と定着（セキュリティ確認テスト、スキル活用の文化づくり） |
フェーズ1：開発チームへの先行導入（2〜3月）
なぜTeamプランか
実はTeamプラン契約の前に2025年7月ごろから、まず3名が個人契約プランで試用し、開発業務で活用できる見通しをたてるために検証していました。手応えはあった一方で、個人契約のまま利用人数を増やすには2つの課題がありました。
- 入力した内容が学習に使われないための設定などが個人の設定作業に依存し、設定漏れのリスクがある
- 請求書や領収書を会社の管理書類として個別に集める必要があり、管理が煩雑になる
そのため、開発チーム全体への導入では「個人プランの寄せ集めにしない」ことを最初に決めました。Team/Enterpriseプランでは、Anthropicの商用利用規約で顧客コンテンツがモデル学習に使われないことが契約上保証され、請求も組織に一本化されます。さらに導入時に以下を設定・確認しました。
- 組織設定で「チャットを評価」をオフ（フィードバック経由でデータが学習に使われるリスクを排除）
- Development Partner Programに未参加であることの確認
CLAUDE.mdとsettings.jsonをセットで配布
エンジニア向けには、Claudeへの行動指示書であるCLAUDE.mdと、ツールの権限を制御するsettings.jsonを2点セットで配布する形で導入手順を整備しました。CLAUDE.mdには回答言語や出力フォーマットだけでなく、「破壊的な操作（更新・削除・初期化など）を自動実行しない」「機密情報を出力しない」といった安全ルールを記述し、settings.jsonのdeny設定と二重でガードをかけています。
先行導入で得た学び
実際に使い始めると、ドキュメントだけでは分からなかった注意点が見えてきました。代表例を紹介します。
- 参照系コマンドの落とし穴：catやgrepなどはファイル内容を読めるため、.env等へのdenyルールをバイパスできます。機密ファイルを操作対象に含むコマンドの許可には注意が必要です。
- スクリプト実行の落とし穴：スクリプトファイルの中身に何があっても、実行時の確認は1回です。実行前に中身を確認する運用を徹底しました。
- 運用Tips：コンテキストをこまめにクリアすると精度とトークンの消費効率が改善すること、複雑でない作業は軽量モデルを使うと利用上限に余裕ができることなど、チームでTipsを蓄積して手順書に反映しました。ただし、その後の新しいモデルのリリースでコンテキスト上限が増えたため、現在はよほど大きな作業でなければクリアが必要な頻度は下がっています。
具体的なエピソードも紹介します。
コミットの自動化はやりすぎだった
Gitのコミット・プッシュを確認なしで実行できる設定を試しました。すると、こちらが差分を確認する間もなく、Claudeが「修正してコミット・プッシュしました！」と進めてしまいます。コミット前の確認は必須に戻しました。
Claudeのメモリが思わぬ挙動を生む
セッションをまたいで記憶されたClaudeのメモリの内容によって、身に覚えのない指示にClaudeが従おうとする挙動に気づきました。メモリ機能の設定方針は、チームで共有しています。
AI専用のGitアカウントは作らなかった
「AI用のGitアカウントを分けるべきか」という議論もありました。しかしAIだけで完結する作業は少なく分離しきれないため、アカウントは分けず、アクセストークンに強い権限を与えない運用に落ち着いています。
フェーズ2：全社展開の準備（4〜5月）
「入れてはいけないもの」を先に決める
全社展開で最初に着手したのは、Claudeの機能紹介ではなく「AI入力NG対象」の整理です。個人情報や認証情報など、Claudeに入力してはいけないデータを先に定義し、全社共通の利用ルールとして文書化しました。アトラスはISMS認証を取得・運用しており、こうしたルールは社内の情報セキュリティ担当と連携しながら整備しています。Claudeの全社導入にあたっては、システム開発グループの技術推進チームが中心となってルールやガードレールを整備しました。
設定を個人任せにしない：組織設定への吸収
当初はエンジニア向けと同様に、非エンジニアにもsettings.jsonを各自で配置してもらう手順でしたが、設定ファイルの配置を個人の作業に依存させると、設定漏れや更新漏れが必ず発生します。設定したのに制御がうまくいかないということもありました。そこで、全社で遵守すべきルールはClaudeの管理画面から組織共通のグローバル指示として登録し、個々の設定ファイルでやっていた制御を組織設定側に寄せました。組織アカウント全員に管理者側の設定が適用されることをテストで確認したうえで展開しています。
これにより、エンジニア向けと非エンジニア向けで手順の差分が小さくなり、展開コストと統制の両方が改善しました。
非エンジニア向け手順書の工夫
エンジニア向け手順をそのまま流用せず、Claude Cowork用にアカウント登録からデスクトップアプリのインストール、セキュリティ確認までを一本道でたどれる手順書を別途用意しました。スクリーンショットを多用し、専門用語を極力減らすことを意識しています。
フェーズ3：展開と定着（5〜6月）
マネージャー先行利用と「準備ができたグループから」の順次展開
非エンジニアへの展開では、いきなり全員にアカウントを配布する方法を取りませんでした。3月中旬から5月にかけて、フェーズ2の準備と並行して、3月中旬から5月にかけて各グループのマネージャーやリーダーに先行利用してもらい、グループでの活用イメージづくりと、定型業務をClaudeのスキルとして準備する作業を進めてもらいました。そのうえで、活用の準備が整ったグループから順次メンバーへアカウントを配布しました。
ツールを配るだけでは、文章チェックや調べ物といった使い方にとどまるメンバーが出てきます。「自分のグループの業務でどう使うか」の道筋とスキルを先に用意してから配布したことで、一斉配布よりスムーズに活用が立ち上がったと考えています。
アカウント運用の設計
メンバーの招待はマネージャー（オーナー権限）が実施し、シートは原則Standardを割り当て、利用上限に頻繁に達するユーザーのみPremiumに切り替える運用にしました。退職・異動時のアカウント削除とシート数調整の手順も最初に決めてあると、運用が迷いません。
展開して終わりにしない：各自でのセキュリティ確認
全社展開時には、各メンバーが自分の環境で以下を3点確認するステップを手順に組み込みました。
- 認証情報検出テスト：ダミーのAPIキーを入力し、警告が表示されることを確認
- ファイル削除承認テスト：ダミーファイルの削除を依頼し、実行前に承認が求められることを確認
- フォルダチェックスクリプト：Claudeにアクセスを許可するフォルダに機密ファイルが含まれていないかをWindows/macOSそれぞれのスクリプトで点検
「ルールを読んで終わり」ではなく、安全装置が動くことを各自が体験することで、セキュリティへの納得感と安心感が得られます。
質問できる場所を用意しておく
全社展開にあわせて、Claudeの使い方やエラーについて気軽に質問できるSlackチャンネルを用意しました。といっても新設したわけではなく、先行導入のトライアル期間に使っていたチャンネルを、正式導入後もそのまま質問窓口として引き継いだものです。
手順書をどれだけ丁寧に書いても、想定外は必ずどこかで起きます。実際、次に挙げるつまずきの多くは、このチャンネルに投稿された「手順どおりにやったのですが、できませんでした」という一言から見つかったものでした。先に使い始めたメンバーが答え、その内容を手順書に反映する。この循環で、手順書がブラッシュアップされていきました。
つまずきポイントの実例
- Windows環境：デスクトップアプリ利用に開発者モードの設定が必要になるケースがあり、手順書に追記しました
- PowerShell：チェックスクリプトが実行ポリシーでブロックされるエラーが多発し、回避手順を整備しました
- 検証時の切り分け：組織設定が意図どおり効いているかを確認する際、個人で配置していた
CLAUDE.mdの指示も併せて働くと組織設定単体の挙動を切り分けられないため、いったん退避してから検証する手順にしました
アトラスではエンジニアはMacを使い、非エンジニアはWindowsを使っています。OS差異によるつまずきは非エンジニアを含む全社展開の準備時に露見しました。Windowsユーザー数名での先行検証で検出できる部分なので、これから導入する方にはOSの利用パターンも想定した先行検証をおすすめします。
定着の仕掛け：スキルを「作って共有する」文化へ
導入後は、各チームが定型業務をClaudeのスキルとして作成・共有する動きが生まれています。野放図にするとカオスになるため、命名ルール（チームプレフィックス＋動詞＋対象）と、確実に呼び出されるためのdescriptionの書き方ガイドを整備しました。
エンジニア側では、実装・テスト・レビュー用のスキルをリポジトリに同梱し、チーム全員が同じスキルで開発できるようにしています。コーディング規約はドキュメントを唯一の情報源（SSOT：Single Source of Truth）とし、スキルには転記しない設計ルールも文書化しました。画面文言の修正のような定型改修もスキル化され、日常の開発フローに組み込まれています。
効果は非エンジニア側にも広がりました。チャットに「朝礼」と入力するだけで当日の勤怠情報を集めた朝礼資料が数分で自動出力される部門もあります。さらに、スキル作成自体を対話でガイドする社内スキルも公開され、エンジニアでなくても業務のスキル化を進められるようになりました。
これから導入する人へ：特に注意が必要な6つのポイント
- AIツールの法人契約前に、データの扱いを確認する（学習に使われないプランか、「チャットを評価」などのフィードバック設定は適切か）
- AIツールの機能紹介より先に「入力NG対象」を決める
- 設定を個人任せにせず、組織設定で一括統制する
- 非エンジニア向けは手順を分けて作る
- OS差異（特にWindows）は小規模に先行検証する
- 一斉導入ではなく段階展開にする（開発チーム→全社。全社内もマネージャー先行で準備が整ったグループから）
おわりに
契約から4ヶ月で、エンジニアの開発支援から非エンジニアの日常業務まで、Claudeが全社のインフラになりました。振り返ってみると、全社AIツール導入とは、ツールを配ることではなく、全員が安全に使えるルールと統制を設計することでした。この記事がこれから導入する方の手探りを減らせれば嬉しいです。
アトラスでは、AIツールを活用して業務を改善しながら一緒に進める仲間を募集しています。興味を持たれた方は採用ページもご覧ください。
