この記事は Merpay & Mercoin Tech Openness Month 2025 の 4 日目の記事です。
こんにちは、Merpay の Payment Core チームでエンジニアリングマネージャーをしている komatsu です。
普段は決済基盤を開発するチームのマネージャーをしており、最近では社内で AI/LLM 関連の導入や登壇などもしています。
この記事では、私たちの組織で実施した「PCP LLM Week」という取り組みについてのレポートと、イベントを通して得られた知見についてご紹介します。
PCP LLM Week は、50 人程度のエンジニア組織で一週間にわたって一切の手動コーディングを禁止し、AI/LLM のみを使用した開発を強制的に行うという、かなりチャレンジングな実験でした。
PCP LLM Week とは
2025/05/08 から 2025/05/14 までの 1 週間にわたって、Merpay の Payment & Customer Platform (PCP; Payment Core チームを含む、決済基盤や KYC、パートナー向けの基盤機能の開発をするチームが所属する領域) 内で実施しました。
対象となったのは約 50 名のメンバーで、バックエンドエンジニア、クライアントエンジニア、QA エンジニア、そして各チームのエンジニアリングマネージャーを対象に開催しました。
このイベントの最大の特徴は、期間中は手動でのコーディングを基本的に禁止し、LLM のみを使用して開発を行うという厳格なルールを設けたことです。
なぜ始めたのか: 組織の課題と解決策
この取り組みを始めた背景には、メンバーとの 1on1 や普段のコミュニケーションの中で上がっていた以下の課題がありました。
- 学習機会の不足: 多くのエンジニアが AI/LLM に興味を持っていたものの、日々の業務が忙しくまとまった学習時間を確保できない
- 組織的な情報格差: 全社的に進めているライセンスやセキュリティの整備状況が全員に伝わっておらず、何を使ってよいのか分からない
- 高度な活用方法の未習得: MCP (Model Context Protocol) を活用したドキュメント連携や Slack 連携などの応用的な使い方を試せている人が少ない
- 情報交換の機会不足: AI/LLM についてエンジニア間で気軽に情報交換する機会が限られている
参考事例: 強制的な学習環境の効果
今回の PCP LLM Week は、ある企業の CTO が「エンジニアのコーディングを禁止する」という指令を出した事例とその結果を参考にして企画しました。
この事例では、短期的には生産性が約半分に低下したものの、AI の得意・不得意分野が明確になり、組織全体の AI 活用能力向上という長期的価値を確認できたと報告されていました。
私たちも同様のアプローチを取ることで、個人の自発的な学習に頼るのではなく、組織として確実に AI/LLM と向き合う機会を作ることができると考えました。
ツール選択: なぜ Cursor なのか
今回のイベントでは以下の理由から主に Cursor エディタを推奨しました。
- 学習環境の共有: 全員が同じツールを使うことで、知見の共有やサポートがしやすい
- 高度な機能: MCP ツールとの連携など、より発展的な使い方を学べる
- 実用性: (企画時点において) 実際の業務で継続的に使用できるレベルの機能を持っている
Kotlin や Swift を主に扱うクライアントエンジニアにとっては制約が大きくなりますが、全員が同じツールを使うことで統一された学習体験を提供し、知見の共有やサポートをより効果的に行うことができると判断しました。
また、当時社内では GitHub Copilot も利用可能でしたが、社内での Cursor への注目や性能を加味して原則 Cursor に寄せました。
設計思想: 目標とルール
イベントを有意義なものにして、同じ方向に向かっていくためには適切な目的と目標設定が必要です。
そのため、イベントを企画したタイミングで考え、モチベーションやゴールを記載したドキュメントを作成し、事前に参加メンバーに共有しました。
目的と目標
Motivation
- AI/LLM がエンジニアの開発スタイルを大きく変革している昨今に、「実際の開発現場でどの程度活用できるのか」を組織全体で実践的に検証する
- 日常の開発業務を LLM のみで実行することにより、AI との効果的な協働方法や、人間が担うべき領域との適切な境界線を、チーム全体で発見・共有する
Goals
以下の 5 つをイベントの目標として設定しました。
- LLM の能力と限界を直接体験する: LLM によって何ができて何ができないのかを肌で感じる
- 開発ワークフローの最適化戦略を構築する: LLM を現在の開発プロセスに効果的に統合し、持続可能な生産性向上を実現するための実践的な活用戦略を学ぶ
- AI コラボレーションスキルを習得する: プロンプトエンジニアリングや LLM による問題分解のスキルを身につける
- 開発パラダイムの再考: 従来のコーディングアプローチをゼロベースで考え直し、新しい問題解決アプローチを探求する
- AI 拡張時代への適応: 開発者の役割がどのように変化していくかの洞察を得る
LLM は開発プロセスにおける大きなパラダイムシフトですが、愚直に適用すると既存のプロセスに LLM を上乗せするだけになってしまいます。
LLM を体験して既存の業務プロセスに適用するだけでなく、ゼロベースで開発プロセスやエンジニアのあり方を見つめ直すことが近年の AI/LLM 時代に必要だと考え、このような構成にしました。
Non-Goals
一方で、以下は今回のイベントの目標ではないことを明確にしました。
- イベント期間内の生産性向上: あくまで中長期的な生産性向上の一環であり、短期的な生産性低下は気にしない
この取り組みを実現するために、Director、VPoE レベルでの組織的な意思決定を行い、短期的な生産性低下を許容して学習投資として位置づけることで、エンジニアが安心して実験できる環境を整備しました。
ルール設計
厳格なルールを設けることで、全員が LLM と向き合う環境を作りました。
基本原則
- 手動コーディングの完全禁止: 一行のコード修正であっても、必ず LLM を通して行う
- 小さな編集も例外なし: 変数名の変更、コメントの追加など、些細な変更も LLM で実施する
- 普段の業務での実践: 特別なタスクを用意するのではなく、日常業務を LLM で行う
許可される例外
- 緊急対応: インシデント対応やシステム障害への対処
- 締め切り間近のタスク: リリース直前など、時間的制約が厳しい場合
- 環境設定: LLM ツール自体のセットアップや設定変更
ドキュメント作成
- LLM による作成を推奨: 技術仕様書、設計書、README 等は LLM で作成することを推奨
- 手動修正は許可: LLM が生成した内容の事実確認や微調整は人間が行ってもよい
なぜ日常業務で実践するのか
今回のイベントでは、特別なタスクやサンプルプロジェクトを用意するのではなく、これらの理由から、あえて普段の業務に LLM を適用することにしました。
現実的な活用可能性の検証
- 実際の業務環境で LLM がどの程度役立つのかを正確に把握するため
- 理想的な条件ではなく、制約のある現実の中での効果を測定するため
- 既存のコードベースや技術スタックとの相性を確認するため
真の課題と限界の発見
- サンプルプロジェクトでは見えない、実業務特有の困難さを体験するため
- レガシーコードや複雑な依存関係がある環境での制約を理解するため
- ドメイン知識が必要な場面での LLM の限界を実感するため
継続可能性の評価
- イベント終了後も継続して使えるかどうかの判断材料を得るため
- 日常的なワークフローに LLM を組み込む際の現実的な課題を把握するため
- チーム開発や既存プロセスとの統合における問題点を発見するため
組織全体での実用性確認
- 個人の実験レベルではなく、チーム・組織レベルでの実用性を検証するため
- 異なる役割 (バックエンド、フロントエンド、QA、マネージャー) での効果の違いを確認するため
- 実際のプロダクト開発における生産性への影響を測定するため
これらの方針によって、より実用的で価値のある知見を得ることを狙いとしました。
実施スケジュール
イベントは参考にした事例と同じく 1 週間の構成で実施しました。
初日 (5/8) にイベント紹介、他部署の AI 活用事例紹介、Cursor ハンズオン、設定・開発時間を行い、その後 1 週間 (5/8-5/14) 各自で普段の開発業務に AI/LLM を活用し、最終日 (5/14) に成果発表会を開催しました。
成功例と課題: 実践から見えた現実
イベント後にアンケート調査を行ったりメンバーとの 1on1 を通してさまざまなフィードバックを得たりしました。
全体的な満足度と効果
まず、メンバーのイベントに対する満足度について、多くの (92%) メンバーがイベントを効果的に活用し、その機会に満足していました。
特に初日に細かい設定について話し、まとまった準備時間を取ることで社内で開発されている MCP ツールの導入など、発展的な設定までできたことが良い体験だったという声もありました。
また、アンケート結果から、参加者のスキルレベルによって異なる効果が見られました。
このイベントによって、多数の「初心者」だったメンバーが「中級者」へとレベルアップしました。
LLM ツールを初めて使う人にとって、強制的に使用する環境が効果的な学習機会となったようです。
基本的な使い方から応用的な活用方法まで、短期間で幅広く体験できたことが、さまざまな知見の習得につながったと思われます。
一方で、既に「上級者」レベルの参加者については、さらなるレベルアップは限定的でした。
これらのメンバーには、より高度な学習機会や異なる学習スタイルが必要であることが判明しました。
ただし、上級者には他のメンバーへの指導やベストプラクティス共有という重要な役割があり、組織全体の底上げに大きく貢献していました。
アンケート結果では、ほぼすべて (96%) のメンバー が「今後も使い続けたい」と回答しており、スキルレベルに関わらず継続的な活用への意欲が高いことが確認できました。
この記事の執筆時点の統計を見ると、使用頻度の差はありますが、PCP における Cursor の使用率は非常に高い水準になっていました。
このイベントが多くのメンバーがツールを習得し、スキルレベルの底上げに寄与したことが一つの要因だと思うので、主催者としてはとても満足しています。
期間については、ほとんどの参加者が「1 週間が適切」と回答しており、学習効果と業務への影響のバランスが良好であることが確認できました。
短すぎず長すぎない、集中して取り組める期間として評価されています。
実際、普段のアサインもある中でこれ以上長いと多少支障が出てきますし、短すぎても消化不良になる可能性もあるので、適切な期間設定だったと感じます。
実際の参加者の声もいくつか紹介します。
全く触ったことがない状態だったが、Copilot のときと同様に無くてはならないものになった。簡単な仕事なら AI で完結できる感覚がある。
どのように指示するかでアウトプットのクオリティは変わるものの、もう開発に使用できるレベルまで LLM の信頼性があったことに驚いた。
社内のドキュメントや repository をワークスペースに追加することで、社内の技術基盤や事情に沿ったコーディングを LLM がしてくれた体験が良かった。
元々かなり有用だという噂を聞いていた程度だったが、実際に使ってみてその効果を実感できたため、どのように活用できるかをタスクごとに考えるようになってきた。
It seems to allow us to work more efficiently by being able to review many lines of codes and files to find and summarize information. It also allows us to peek at where it found such information to confirm the accuracy of its results as well. It’s also able to help refactor and find unused code as well.
曖昧な指示だとずれた変更が行われるのでコンテキストを明確にする必要があり、自分がやろうとしていることをコンテキストなしの状態から言語化するところに慣れが必要だと感じた。また、一見自然言語でも通じるように見えるので素朴に質問してしまいがちだが、特に MCP server などでは内部でどのような問い合わせが行われるのかを理解した上での利用が必要といった難しさがあると感じた。
コード生成にはまだ一定の限界がある。一発ではできない。k8s や tf のレポジトリはファイルが多すぎるため LLM にとってはノイズになることもある。
多くのメンバーの LLM に対する信頼度が向上し、その活用方法についても考える良い機会になったことが伺えます。
また、同時に現状の LLM の性能の限界を理解する良い機会にもなり、どのようなタスクに適用していくかの洞察を得ることができました。
成功例: LLM の可能性を実感した瞬間
開発効率の大幅向上
- テスト作成、API 修正などの定型的なタスクで劇的な時間短縮
- 既存コードの解析や大規模リファクタリングでの威力
- ボイラープレートコード生成による生産性向上
高度なコーディング支援
- Cursor や GitHub Copilot による的確な修正提案
- 複雑なコード生成による協働的な開発体験
- 一発で修正箇所を発見できる精度の高さ
ワークスペース統合とドキュメント活用
- 社内ドキュメントやリポジトリとの連携による組織固有の技術基盤に沿ったコード生成
- 既存データソースを基にした技術仕様書の自動生成
- MCP を活用した Confluence の仕様から Jira チケットの自動生成
プロンプトエンジニアリングの重要性の理解
- 明確で詳細な指示の重要性 (人間への指示と同様)
- プロンプトの品質が出力品質に直結することの実感
当初の狙い通り、多くのメンバーが直近の LLM の性能について理解し、活用できる開発プロセスを発見していました。
また、MCP や v0.50 でちょうど追加されたワークスペース機能なども駆使し、複数マイクロサービスに跨った開発なども可能となり、高度な活用をしているメンバーも多々いました。
課題: 直面した限界と困難
また、イベントを通して現状の AI/LLM の課題も見えてきました。
精度と品質の問題
- 不正確な出力や意味不明な結果の生成
- 複雑で非標準的な概念への対応困難
- コード品質の一貫性の欠如
効率性とワークフローの課題
- AI との反復的なやり取りによる時間コスト
- 特定タスクでは人間の方が依然として高速
- 既存ワークフローとの統合やツール切り替えの煩雑さ
- AI 生成コンテンツの検証時間が手動作業と同等かそれ以上
プロンプトとコンテキストの難しさ
- 曖昧な指示に対する AI の対応困難
- 大規模で複雑なコンテキストの処理限界
- 自分の要求を詳細に言語化することの困難さ
知識ギャップと限界
- ドメイン固有知識やインターネット上にない情報への対応困難
- 暗黙知やコードで明示されていない側面の理解不足
技術領域による制約
- iOS/Swift 開発など、特定の技術スタックでの効果的な活用の困難さ
当然ではありますが、コードや仕様には載っていない各メンバーが持っているドメイン知識を適切に伝えるには一定の負荷がかかり、そのことが生成されるコードの限界になることがわかりました。
これを機に私のチームではドキュメンテーションを自動化したり不足しているコードコメントを追加したりするといった次のアクションにつながっており、良い学びができたと感じています。
また、強制的な機会だったからこそ、AI でできることの限界を知ることができました。
開発に対する考え方の変化
イベントを通じて、メンバーの開発に対する考え方に以下のような変化が見られました。
実用性への確信の高まり
- 「思っていたより実用レベルに達している」という認識の変化
- 従来の開発手法を置き換える可能性への確信
- コード編集などの特定領域での代替可能性の実感
戦略的活用の理解
- 全てのタスクの代替ではなく、適材適所での活用の重要性
- 設計ドキュメントやコードレビューなど特定用途での高い効果
- 人間の専門知識を最終段階に残すプロセスの有効性
継続学習の必要性
- 効果的な使用方法を見つけるための実験の重要性
- 他者の経験から学ぶことの価値
- ベストプラクティスの継続的な学習の必要性
組織的なシナジー効果
- 全員が LLM を使うことで生まれる相乗効果への気づき
- チーム間での活用度合いの差とベストプラクティス共有の重要性
実際に全員で使うことで、どのように LLM を活用していくのか、どのようにエンジニアの役割が変わっていくのかといった当初の目標を考える有意義な機会になりました。
また、継続的に知見の共有や学習を続けていく必要性も再度実感できたと思います。
マネージャー視点: 組織運営への影響
EM の観点でも多くの学びがありました。
組織運営に関する学び
まず、強制力の重要性を痛感しました。
普段から AI/LLM という声は多く聞いていましたが、実際には日々の業務に追われて学習時間を確保できないメンバーがほとんどでした。
今回のように組織全体で取り組む期間を明確に設けることで、全員で LLM に真剣に向き合う機会を作ることができました。
PCP のメンバーは自走力の高いエンジニアが多いですが、そのような環境だとしても自発的な学習だけに頼らず、組織全体としてのスキルアップの機会を提供することの重要性を再確認しました。
次に、情報共有の活性化が想定以上の効果を生みました。
イベント用に作成した専用 Slack チャンネルは、当初は質問や困りごとを共有する場として考えていましたが、実際には知見の共有やちょっとした発見の報告など、非常に活発なコミュニケーションの場となりました。
イベント終了後も継続的な学習コミュニティとして機能しており、組織の学習文化醸成に大きく貢献しています。
そして、スキルレベルの標準化という予想外の効果も得られました。
これまでは AI/LLM の活用レベルに個人差が大きく、チーム間での知見共有も限定的でした。
しかし、全員が同じ体験をすることで、組織全体の AI リテラシーが底上げされ、共通言語で議論できるようになったのは大きな収穫でした。
生産性への現実的な影響
短期的には実際に生産性が多少低下しましたが、これは組織として予想し、受け入れていた結果でした。
また、個人的には予想していたほどの生産性の低下は見られず、直近の LLM の性能向上による恩恵が大きいと感じています。
同時に生産性観点でも長期的な価値を確認できました。
- 適材適所の理解: どのタスクに AI が向いているかの判断力向上
- 開発スタイルの変化: プロンプトエンジニアリングを通じた問題分解能力の向上
- AI ファーストな思考習慣: 課題に直面した際に AI による解決を当然の選択肢として考える習慣の定着
- 個別最適化されたワークフロー: 各メンバーが自身の開発スタイルに最適化された AI ツールの組み合わせと活用方法を確立
特に AI による解決策を常に考える習慣ができたことは、ゼロベースでアプローチを考え直す上で非常に価値ある体験だったと感じています。
また、この結果は、組織のリーダーシップが「短期的なコストを払ってでも、長期的な AI 活用能力を獲得する」という明確な意思決定を行ったからこそ実現できたものであり、組織として成長していくことへの重要性を再度確認しました。
マネージャーアンケートから見えた現実
マネージャー向けのアンケートでは、AI 導入による生産性向上とリソース計画への影響について以下のような現実的な見解が得られました。
生産性向上への見通し
生産性向上については、短期的な劇的な変化ではなく、中長期にわたって徐々に向上していく見込みであることが分かりました。
現在はツールの乱立や性能差の変化により、短期では一長一短の状況が続いており、これから模索や選定を継続的に行っていくことが重要です。
また、AI の効果は作業の種類と開発者の LLM 経験に大きく依存することも明らかになりました。
適切なタスク選択と生産性維持のためのトレーニングが重要であり、特に問い合わせ対応や運用系など、直接的な生産性に結びつかないタスクでの効率化に期待が寄せられています。
リソース計画への影響
現時点では従来のリソース計画手法を大幅に変更するレベルの変化は見られませんでした。
また、短期で AI によってリソースに大幅な余裕が出るには依然として壁がありますが、組織横断の開発スタイルは導入しやすくなったという手応えを感じています。
段階的な環境整備が現実的なアプローチであることが確認できました。
マネージャーとしての学び
組織的な取り組みの価値として、IC からの結果を聞いて想定よりも課題が多いことを実感しました。
一方で、全員が使うことで生まれるシナジー効果を確認でき、組織として LLM にどう寄り添っていくかを考える機会の重要性を認識しました。
現実的な期待値設定については、短期的な劇的な生産性向上への過度な期待は禁物であることが分かりました。
中長期的な投資として捉え、継続的な学習と改善が必要であり、ツールの組み合わせや切り替えの最適化が今後の課題となります。
その後の展開: 継続的な取り組み
イベント最後には以下の項目でメンバーを表彰し、効果的な活用方法を共有しました。
- LLM Code Generation Champion: 最も多くのコードを生成した人
- LLM Refactoring Champion: 最も多くのコードを削除 (リファクタリング) した人
- Precision Prompter: 最も高い Accept Rate を達成した人
同僚がどのように活用できているかを間近でシェアすることで、全員がより自分ごととして AI スキルセットに対する理解を深めたり、期ごとの個人目標に追加したりと、全体的な AI に対する視座向上ができたと思います。
継続的な取り組み
- 情報共有チャンネルの継続: イベント用 Slack チャンネルを汎用的な名前に変更し、継続的な情報交換の場として活用
- ベストプラクティスの共有: 効果的な活用方法を組織内で継続的に共有
- 新機能のキャッチアップ: AI/LLM ツールの新機能を組織全体で迅速に取り入れる体制構築
まとめ
PCP LLM Week は、短期的な生産性低下というコストを払いながらも、全員で体験することで組織全体の AI 活用能力を大幅に向上させる貴重な機会となりました。
特に重要だったのは、「全員で同じ体験をする」ことで生まれた学習効果と、その後の継続的な情報共有文化の醸成です。
AI/LLM の活用は個人のスキルに依存する部分が大きいですが、組織として取り組むことで、より大きな価値を生み出せることを実感しました。
特に昨今のモデルやエコシステムの進化は個人でキャッチアップしていくにはあまりに膨大なため、組織として方向性を示し、スキルアップの機会を提供することでモチベーションを獲得し、各メンバーの自走力に繋げる良いサイクルが生まれると感じました。
今後も組織として AI-Native になるための機会や仕組みを継続的に作っていきたいです。
明日は同じく PCP の foghost さんによる「決済基盤の新たな挑戦: 決済チェックアウトソリューションの開発」です。
引き続き Merpay & Mercoin Tech Openness Month 2025 をお楽しみください。
