GMOペパボのClaude Code活用：個人のツールを「組織の資産」に変えた設計
Claude Codeとは何か
Claude Codeは、AnthropicのAIアシスタントClaudeをコマンドラインやエディター上で動かすための開発ツールです。コードの生成・レビュー・テストといったエンジニアリング業務にとどまらず、ブラウザ操作やAPIコールも扱えるため、稟議処理や経費精算といった非コーディング業務にも応用できます。
2026年2月、asken・GMOペパボ・Omiaiの3社は「Claude Code実践テックトーク」と題した合同LTイベントを開催しました。このイベントは、Claude Codeを開発で活用しているものの「どう使い込めばいいか」「どこまで任せていいか」という課題を感じているエンジニアやエンジニアリングマネージャーに向け、実践ノウハウを共有する目的で企画されました。 Pepabo本稿では、GMOペパボの2つの登壇内容を軸に、組織規模でのClaude Code活用の実像を紹介します。
プラグインマーケットプレイス：知見を「個人資産」から「組織資産」へ
23のプラグインで業務全般をカバー
GMOペパボ事業開発部のugo氏は、Claude Codeの社内活用を「個人の便利ツール」の段階から脱却させるための仕組みを発表しました。
ペパボでは社内向けに「pepabo-marketplace」を構築し、コーディング支援にとどまらず勤怠承認・稟議の起案や添削・スライド作成・SUZURI API連携など業務全般をカバーする23のプラグインを共有しています（発表時点。2026年3月初旬には59個に増加）。 Pepabo
Claude Codeの「プラグイン」とは、スキル・フック・エージェント・MCPサーバーをひとまとめにした配布単位です。エンジニアが個人的に育てたプロンプトや手順を、インストールするだけで誰でも同じ品質で再現できる形式にパッケージ化するものと理解すれば近い。
自動化されたマーケットプレイス運用の仕組み
プラグインの数が増えると、運用上の問題が出てきます。マーケットプレイスの運用では「コンフリクト」「使われない」「似たスキルの増加」という3つの課題に直面しました。 Pepabo
各課題への対処も、人手ではなく仕組みで解決しているのが特徴です。
- コンフリクト：mainブランチへのPushをトリガーにAIエージェントが該当PRを検出し、
marketplace.jsonを自動でリビルド - 認知不足：PRのマージ時にGitHub ActionsとDify経由でSlackへ自動告知
- 類似プラグインの増加：PRオープン時にClaude Codeが既存プラグインと比較し、統合を提案・自動実行
これらの自動化により、量の増加・品質の維持・認知の拡大・改善のフィードバックという好循環が自律的に回り続けています。 Pepabo
業務のスキル化を日常的なサイクルに組み込む
さらに踏み込んだ取り組みとして、あらゆる業務をClaude Code上で行うことで、セッションログからスキル化できるタスクを発見するプラグインも存在します。Claude CodeはCLI・API操作だけでなくブラウザも操作できるため、稟議や経費精算といった非コーディング業務もプラグインにできます。 Pepabo
「業務をこなす」→「ログからパターンを発見する」→「プラグインに昇華させる」という循環を設計に組み込むことで、組織の知見が継続的にマーケットプレイスへ蓄積されていく構造です。
セキュリティと自動マージ：AIがPRを量産する時代の開発フロー
AWS Bedrock Guardrailsの「理想と現実」
SUZURI・minne事業部の中山一仁氏は、Claude Codeを組織に安全に導入するためのセキュリティ検証を発表しました。
機密情報保護を目的に、AWS Bedrock GuardrailsのPII（個人情報）フィルターを活用しようとしたところ、想定外の問題が発生しました。Claude Codeが背後で送信する「巨大なシステムプロンプト」自体がフィルターに接触してしまい、挨拶などの無害な入力さえも全ブロックされてしまうという、実践的な「ハマりどころ」が浮き彫りになりました。 Pepabo
デバッグにも困難が伴います。標準のCloudWatch Logsでは「ブロックされた事実（INTERVENED）」しか記録されず、具体的にプロンプトのどの部分が検知されたのか特定できません。 Pepaboそこでapply-guardrail APIを用いてテキスト断片を逐次テストする手法で原因を絞り込み、システムプロンプト内の特定のメールアドレスがPIIとして誤検知されていることを突き止めました。
リスクベースの「3段階パイプライン」
セキュリティ対策と並行して、中山氏はAIがPRを量産する時代に見合ったレビューフローの再設計も提案しました。
AIがコードの文脈から「影響範囲」を分析し、リスクに応じたサイズラベル（size/XS〜XL）をPRに付与します。タイポ修正や依存ライブラリ更新といった低リスクなPRについては、AIレビューのみで条件付き自動マージ（Auto Merge）を実施します。 Pepabo
これは「1日で8本のPRを生成した」という数字の背景にある設計思想です。重要なのはPRの本数ではなく、リスクの低い変更を人間がレビューするコストをゼロに近づけることで、エンジニアの判断力を本当に必要な場所に集中させるという構造にあります。
この取り組みから学べること
GMOペパボの事例は、Claude Code活用の「次のフェーズ」を示しています。個人が便利に使うツールから、組織全体で品質と速度を高め合うインフラへの転換です。
特に注目すべき点は2つあります。まず、自動化の自動化という発想です。マーケットプレイス自体の運用（コンフリクト解消・告知・統合）をすべてAIに任せることで、プラグインの数が増えても管理コストが増加しない設計になっています。
次に、リスク分類による人間の集中投資です。すべてのPRに同じ重さでレビューを割り当てるのではなく、AIが影響範囲を判断してトリアージする仕組みを入れることで、エンジニアが高リスクの変更に集中できます。
どちらの取り組みも、「AIに任せる範囲を広げる」ことと「人間の判断が必要な場所を守る」ことを、設計の段階から意識して両立させています。業務自律化を検討する際の実践的な参考事例といえるでしょう。
