社内向けの AI ツール導入が進むなか、「現場が使いこなせない」「ライセンス管理が混乱する」「利用状況の可視化ができない」という声を多くの IT 部門から伺います。私がデジライズで Claude Code の法人導入を支援する際も、こうした課題は非常に頻繁に挙げられます。特に数百〜数千人規模の組織では、個別のライセンス配布だけでなく、誰がどの用途でどう使えるのかを明示し、利用申請から承認・払い出しまでを統制する「サービスカタログ」の仕組みが鍵になってきます。本記事では、Claude Code を社内セルフサービス基盤として機能させるためのサービスカタログ設計の要点を、構成要素・ワークフロー設計・継続改善の観点から整理します。
本記事の結論: サービスカタログを「分類・申請・ガイド・モニタリング」の 4 要素で設計し、公開後 3-6 ヶ月の利用パターン観察で定常化させる
サービスカタログの役割と設計の前提
Claude Code を単にライセンス配布するだけでは、誰がどの業務で使うべきかが現場に伝わりません。結果として「試しに使ってみたが続かない」「部門ごとに独自の使い方をして知見が分散する」といった事態が起きます。サービスカタログとは、社内の AI ツール群を製品カタログ風に一覧化し、利用条件・申請フロー・サポート範囲を明示する仕組みです。IT サービスマネジメント(ITSM)の文脈では一般的ですが、AI ツールにおいても同様の考え方が有効です。
設計時の前提: 初期は 3-5 種類の「サービスメニュー」(例: コード生成支援、ドキュメント自動化、データ分析補助)に絞り、ユーザーフィードバックで拡充していく
カタログの粒度が細かすぎると選択に迷い、粗すぎると用途が曖昧になります。私の支援経験では、まず「よくある業務パターン」を 3-5 種類に集約し、それぞれに利用条件(部門・役職・データ取扱レベル)と SLA の目安(サポート対応時間・平均応答時間)を設定するアプローチが現実的です。
カタログ構成要素の設計
カテゴリ分類と検索タグ
サービスカタログの第一印象は「一覧のわかりやすさ」で決まります。以下のような分類軸を組み合わせると、ユーザーが自分の用途を見つけやすくなります。
1. 業務カテゴリ — 「コーディング支援」「ドキュメント作成」「データ分析」「ヘルプデスク」など業務領域で分類
2. 対象ユーザー — 「開発者向け」「営業・企画向け」「全社員共通」など役割で区分
3. データ取扱レベル — 「公開情報のみ」「社内文書可」「機密情報対応」などポリシー適合性で分類
4. 検索タグ — 「API 連携」「Slack 統合」「ナレッジベース」など機能キーワードをタグ付け
例えば「コーディング支援(開発者向け・社内コード可)」というサービスメニューには、#コード生成 #リファクタリング #レビュー支援 といったタグを付与し、社内 Wiki やポータルサイトで検索可能にします。これにより、ユーザーは自分の業務文脈に合ったメニューを素早く見つけられます。
利用条件と SLA の明示
各サービスメニューには、誰が・どのデータを・どの範囲で使えるかを明記します。Claude Code の場合、Anthropic 側の利用規約に加え、自社のデータポリシーやセキュリティ基準との整合も必要です。
| 項目 | 記載内容の例 |
|---|---|
| 対象ユーザー | 開発部門の正社員・派遣社員(要セキュリティ研修修了) |
| 利用可能データ | 社内コードベース・技術ドキュメント(機密情報を除く) |
| 禁止事項 | 顧客の個人情報・パスワード・秘密鍵の入力 |
| SLA | 平日 9-18 時のサポート対応、平均応答時間 4 時間以内(目安) |
| 料金モデル | 部門別の月額固定枠、超過分は従量課金 |
SLA は「必ず 4 時間以内に解決」といった保証ではなく、「平均的には 4 時間程度を目指す」といった目安の範囲で示すことが重要です。過度なコミットメントは運用負荷を高めます。
料金モデルについても、全社共通の固定枠を設けるか、部門ごとに予算枠を持たせるか、プロジェクト単位で申請させるかなど、組織の会計ルールに応じて設計します。Claude Code の API 課金体系(トークン単位)を社内の予算管理に翻訳する工夫が求められます。
サービス申請承認ワークフローの設計
カタログを見て「使いたい」と思ったユーザーが、どのように申請し、誰が承認するかのフローを整備します。Claude Code の承認ワークフロー設計で詳述していますが、ここではカタログとの連携を中心に整理します。
1. 申請フォームの提供 — カタログの各メニューに「利用申請」ボタンを配置し、必要事項(用途・期間・データ種別)を入力
2. 承認ルートの自動判定 — 申請内容(データレベル・利用期間)に応じて、直属上長承認 or IT 部門承認 or 両方を自動で振り分け
3. ライセンス払い出しの自動化 — 承認後、Identity Provider(Okta/Azure AD)経由で Claude Code のシート割り当てを自動実行
4. 利用開始通知とガイド送付 — 払い出し完了時にユーザーへメール通知、利用ガイドと FAQ へのリンクを送付
このフローを ServiceNow や Jira Service Management、あるいは社内開発の申請システムと連携させることで、カタログ → 申請 → 承認 → 払い出しの一気通貫を実現します。手作業での Excel 管理や Slack DM での個別対応を減らし、監査ログも自動記録されるため、コンプライアンス上も有利です。
利用ガイドとサンプルコードの整備
カタログに「このサービスは〇〇ができます」と書いても、具体的な使い方が分からなければ利用は進みません。各サービスメニューには、利用ガイドとサンプルコードをセットで提供します。
ガイド整備のポイント: 「5 分で試せるクイックスタート」と「実務ユースケース集」の 2 段構成が効果的
クイックスタートガイド
新規ユーザーが最初の 5-10 分で「動いた」と実感できる手順を用意します。例えば「コーディング支援」サービスなら、以下のようなステップです。
## クイックスタート: Claude Code でコード生成を試す
1. ブラウザで https://claude.ai/code にアクセス
2. SSO でログイン(社内アカウント使用)
3. 左上の「New Chat」をクリック
4. 以下のプロンプトを入力:
「Python で CSV ファイルを読み込み、列の合計を計算する関数を書いてください」
5. 生成されたコードをコピーし、ローカル環境で実行してみる
このレベルの「とりあえず動かす」体験があると、ユーザーは自分で深掘りする意欲を持ちやすくなります。
実務ユースケース集
次に、自社の業務に即した具体例を示します。Claude Code とナレッジ管理の連携やヘルプデスク対応への活用など、既に他の記事で紹介している実例を、カタログ内のガイドとして再構成します。
- 例 1: 過去の障害報告書 100 件を要約し、頻出キーワードを抽出する
- 例 2: 社内 Wiki の FAQ を Claude Code で検索し、問い合わせ対応時間を短縮する
- 例 3: レガシーコードのリファクタリング案を生成し、レビュー会議の資料にする
これらのユースケースには、実際のプロンプト例と期待される出力サンプル、注意点(例: 機密情報は入力しない、生成コードは必ずテストする)を併記します。ユーザーは自分の業務に近い例を見つけ、プロンプトを微調整することで即座に試せるようになります。
サンプルコードとテンプレート
API 連携や Slack Bot 構築など、技術的な統合が必要なサービスメニューでは、GitHub リポジトリや社内 GitLab でサンプルコードを公開します。
# 例: Claude Code API で社内ドキュメントを要約するスクリプト
import anthropic
client = anthropic.Anthropic(api_key="YOUR_API_KEY")
def summarize_document(text: str) -> str:
response = client.messages.create(
model="claude-3-5-sonnet-20241022",
max_tokens=1024,
messages=[{"role": "user", "content": f"以下の文書を 3 行で要約してください:\n\n{text}"}]
)
return response.content[0].text
# 使い方: summarize_document(your_document_text)
こうしたサンプルは、社内のセキュリティポリシーに準拠した形(API キー管理方法、ログ出力先、エラーハンドリング)で提供することが重要です。ユーザーが「そのまま本番で使えるか」を判断できるレベルで整備します。
利用状況ダッシュボードの構築
カタログを公開したら、誰がどのサービスをどれくらい使っているかを可視化するダッシュボードを用意します。これは IT 部門がリソース配分を最適化するだけでなく、ユーザー自身が「自分の利用状況」を確認し、予算枠の残りや推奨事例を知る手段にもなります。
基本モニタリング指標
| 指標 | 目的 | データ取得元 |
|---|---|---|
| アクティブユーザー数 | 各サービスメニューの利用者数推移を把握 | SSO ログ、API アクセスログ |
| リクエスト件数・トークン消費量 | コスト管理と利用傾向分析 | Claude Code API ログ |
| 申請承認の所要時間 | ワークフロー効率の確認 | 申請システムのタイムスタンプ |
| サポート問い合わせ件数 | ガイド整備の優先度判断 | ヘルプデスクチケット集計 |
これらの指標を Tableau や Power BI、あるいは社内の BI ツールで可視化し、週次または月次で関係者に共有します。部門別・サービスメニュー別の内訳を示すことで、「営業部門はドキュメント作成が多い」「開発部門はコード生成の利用が集中している」といった傾向が見えてきます。
ユーザー個別のダッシュボード
ユーザー自身がログインして、自分の利用状況を確認できる画面も有効です。「今月の API 利用量: 1,200 トークン / 予算枠 5,000 トークン」「よく使うサービス: コード生成 (60%)、ドキュメント要約 (30%)」といった情報を示すことで、自己管理意識が高まります。また、「あなたにおすすめのサービス」として、利用パターンが似た他ユーザーがよく使うメニューを提案する機能も、カタログの回遊率を上げる工夫の一つです。
ユーザーフィードバック収集と改善サイクル
カタログ公開後、最初の 3-6 ヶ月は利用パターンが変動しやすい期間です。ユーザーが実際に使ってみて初めて分かる課題(ガイドが不足している、申請承認が遅い、SLA が現実的でない)を吸い上げ、継続的に改善します。
注意: フィードバックを「全て即対応」しようとすると運用が破綻します。優先度を付けて段階的に改善する仕組みが必須
フィードバック収集の手段
- カタログ内埋め込みフォーム: 各サービスメニューのページに「このガイドは役立ちましたか?」5段階評価と自由記述欄を配置
- 定期アンケート: 四半期ごとに利用者全員へ「使いやすさ」「ガイド充実度」「サポート対応」を聞く簡易アンケート
- 利用ログ分析: ガイドページの閲覧時間、離脱率、サンプルコードのコピー率などから、改善余地の高い箇所を特定
- ヘルプデスクチケットのタグ分析: 同じ問い合わせが頻発している場合、ガイドの FAQ に追記
改善サイクルの運用
月次または四半期ごとに、IT 部門とサービスデザイナーが集まり、以下の流れで改善を計画します。
1. データ集約 — ダッシュボード指標、フィードバックフォーム、ヘルプデスクチケットを集計
2. 課題の優先度付け — 利用者数が多いサービスで評価が低い項目、問い合わせ件数が多いテーマを優先
3. 改善施策の決定 — ガイド追記、サンプルコード拡充、申請フロー簡素化、SLA 見直しなど具体策を決める
4. 実施と告知 — 改善内容をリリースし、カタログのお知らせ欄や社内チャットで周知
5. 効果測定 — 次回の集計で改善前後の指標(問い合わせ減少率、満足度上昇など)を確認
このサイクルを 3 回程度回すと、利用パターンが安定し、新規ユーザーのオンボード時間も短縮される傾向があります。ただし「3-6 ヶ月で必ず定常化する」わけではなく、組織の規模や AI リテラシーの水準により前後します。
カタログ設計の実践チェックリスト
最後に、サービスカタログを設計・運用する際の実践的なチェックリストを示します。
| 項目 | 確認内容 |
|---|---|
| カテゴリ分類 | 業務カテゴリ・対象ユーザー・データレベルの 3 軸で整理されているか |
| 検索タグ | 機能キーワード・統合先システム名などのタグが各メニューに付与されているか |
| 利用条件 | 対象ユーザー・利用可能データ・禁止事項が明記されているか |
| SLA 明示 | サポート対応時間・平均応答時間の目安(保証ではなく目安として)が示されているか |
| 料金モデル | 固定枠 or 従量課金、超過時の扱いが説明されているか |
| 申請フロー | 申請フォーム・承認ルート・ライセンス払い出しの自動化が機能しているか |
| クイックスタート | 5-10 分で試せる手順が各サービスメニューに用意されているか |
| ユースケース集 | 自社業務に即した具体例とプロンプトサンプルが 3 件以上あるか |
| サンプルコード | セキュリティポリシー準拠のコード例が公開されているか(技術統合メニューの場合) |
| ダッシュボード | アクティブユーザー・トークン消費・申請所要時間・問い合わせ件数が可視化されているか |
| フィードバック収集 | カタログ内フォーム・定期アンケート・ログ分析の仕組みがあるか |
| 改善サイクル | 月次 or 四半期で集約→優先度付け→施策実施→効果測定の流れが回っているか |
このチェックリストを元に、自社のカタログ設計の抜け漏れを確認し、段階的に完成度を高めていきます。
まとめ
Claude Code を社内セルフサービス基盤として機能させるには、サービスカタログの整備が重要です。カテゴリ分類・検索タグ・利用条件・SLA・料金モデルを明示し、申請承認ワークフローと連携させることで、ユーザーは「何ができるか」「どう使うか」「誰に聞けばいいか」を迷わず理解できます。利用ガイドとサンプルコードをセットで提供し、利用状況ダッシュボードで継続的にモニタリングし、ユーザーフィードバックを吸い上げて改善サイクルを回すことで、3-6 ヶ月程度で利用パターンが安定する傾向が見られます。
カタログ設計は一度作って終わりではなく、組織の成長や AI ツールの進化に合わせて更新し続ける必要があります。最初は 3-5 種類のサービスメニューから始め、ユーザーの声を聞きながら拡充していくアプローチが現実的です。
株式会社デジライズでは、Claude Code の法人導入支援として、サービスカタログ設計のコンサルティングと社内向け利用ガイド作成の研修を提供しています。申請承認ワークフローの自動化設計、ダッシュボード構築支援、継続改善サイクルの伴走支援など、カタログ公開後の運用定着までをサポートします。まずは無料相談で、貴社の現状と課題をお聞かせください。
関連記事
デジライズの実績は社内集計値です。特に明記のない数値付き事例は、匿名加工された実例をもとにしたモデルケースです。導入効果は企業や業務によって異なります。各サービスの料金・機能・提供条件は記事の公開・更新時点の情報であり、変更されるため、最新情報はAnthropic公式サイトなどの一次情報をご確認ください。



