AIに任せる範囲と人が引き受ける判断、PayPayカード審査システムの設計現場

AIが技術的に「解ける」ことと、業務として「解くべき」ことは違う。審査・債権という金融のバックエンド領域では、その線引きを誰が、どのように行うのか。それがシステムの品質を大きく左右する。

本記事では、PayPayカードで審査システムの内製化を進めるテックリード3名と、審査債権開発部の部長がAI駆動開発の現場で試行錯誤している内容を紹介する。業務理解の重要性、ADR（Architecture Decision Record）による判断の再現、AIを活用する能力そのものをチームで底上げする方法、そして金融ドメインで組織的にAI活用を広げる仕組みまで、明日から使える知見が詰まった内容となっている。

アーカイブ動画

AI時代、テックリードの価値を決める業務理解の話

AIによる実装は劇的に速くなった。しかし、そのスピードを本当に成果に変えられているのは誰か。PayPayカードで途上与信システムを担当するテックリードが、月100件のプルリクエストをさばく現場感覚から「AIで伸びるエンジニア」の条件を語る。

PayPayカード株式会社
テクノロジー統括本部
システム本部審査債権開発部
テックリード
嵯峨道明（さがみちあき）氏

与信システムを担うテックリードとしての現在地

嵯峨氏は第二新卒でエンジニアのキャリアをスタートし、SES、フリーランスを経てLINEに入社。その後PayPayカードに出向し、現在は転籍しているテックリードだ。担当しているのは審査領域のなかでも「途上審査」と呼ばれる領域。入会後に定期的に利用者の状況をチェックし、必要に応じて利用枠を上げ下げするシステムを主に開発している。

AIで伸びるエンジニアと伸びにくいエンジニア

Codexを本格的に使い始めて、実装スピードは大きく上がった。しかし嵯峨氏は「全員が同じように速くなるわけではない」と実感している。

伸びやすいのは、業務理解があり、設計・レビュー観点を持っているエンジニア。逆に伸びにくいのは、決まった仕様を実装に落とすだけのエンジニアだ。

その背景には、審査領域の開発現場の特性がある。仕様がきれいに揃った状態で降りてくるケースはほとんどない。仕様を考えて実装しはじめて、「これで本当にいいんだっけ」と業務担当者に聞き、また戻ってきて調整する。この行き来のなかで、AIが出したものを鵜呑みにせず、疑問を持ち直せるかどうかで成果が変わってくる。

嵯峨氏は具体例として、過去データを定期削除するバッチのパラメーター設計を挙げた。メンバーが上げてきたプルリクエストは相対日付（今から90日前）で指定する仕様だったが、運用する人間の感覚に近いのは絶対日付（例: 7月31日以前）のほうだ。AIが出した実装をそのまま採用せず、運用背景を想像して疑問を持てるかどうか。ここに質の差が生まれる。

業務理解を深めるために、業務部門のそばで働く

もう一つ嵯峨氏が重視しているのが業務知識の吸収スピードだ。「自分の中で煮詰めるより、すぐ聞いた方が早い」を徹底しており、Slackでもまとまっていない段階で投げる、思いついたらクイックなミーティングにすぐ誘う、といった動き方をしている。

先週は福岡本社に出張していたが、システム担当者でありながら、業務担当者がいるフロアで多くの時間を過ごしていた。技術担当のフロアではなく業務担当者がいるフロアを選んだ理由はシンプルで、業務の人と一緒に仕事したほうが早いから。開発メンバー同士の連携も大事だが、業務知識を吸収してAIに投げる情報を厚くするほうが、結果としての効率が高いと考えている。

「理想は業務のすべてをプロンプトにして投げること。でも現実問題そんなことはできないので、人と人のやり取りで吸収するしかない」と嵯峨氏は語る。

AIの時代に問われる、業務理解とレビュー能力

伸びるエンジニアの条件について、嵯峨氏はあらためて「業務理解」「運用を想像する能力」「レビュー能力」の3つを挙げた。技術だけを深掘りしてもアウトプットにつながりにくい。

審査領域はBtoCのフロントというよりも、業務担当者の意見が重要になるバックエンドの世界だ。だからこそ余計に、ドメイン知識を持つエンジニアの価値が浮き彫りになる。

次のセッションでは、テックリードが引くべき「システムで完結させない」という線引きを、どのように組織の資産として残すのかが語られる。

システムで完結させないを見極め、その判断をADRで再現可能にする

AIは何でもシステムで解こうとする。しかし、審査業務のように人が判断すべき領域を含む仕組みでは、AIの提案をそのまま採用すると業務が破綻する。PayPayカードで審査システム刷新プロジェクトを推進してきたテックリードが、AIとの協業で得た教訓と、ADR（Architecture Decision Record）を使った判断の残し方を紹介する。

PayPayカード株式会社
テクノロジー統括本部システム本部
審査債権開発部審査開発グループ
テックリード
岡本仁（おかもとひとし）氏

検索する力からAI活用する力へ

岡本氏は2015年からエンジニアとしてキャリアを積み、Java・AWSを使った業務系バックエンド開発を経て、2024年にPayPayカードに入社した。入社後は審査システム刷新プロジェクトに配属され、モノリシックなシステムをクラウドネイティブなマイクロサービスへ進化させる作業を推進している。

冒頭で岡本氏が振り返ったのは、若手時代に先輩から言われた「エンジニアの質は検索して答えを見つけ出す能力で決まる」という言葉だ。Google検索が上手なエンジニアは仕事が早く、正確だった時代。しかし、その常識はここ数年で大きく変わりつつある。キーワードで検索するスタイルから、AIに問いかけ、必要な情報を整理してもらうスタイルへ。岡本氏はいまAI検索という新しい能力に注目していると述べた。

システムで解けることと、システムで解くべきことは違う

本題は「システムで解けること」と「システムで解くべきこと」の違いだ。審査システム刷新の現場でAIに要件や設計を投げると、技術的にはよく整った答えが返ってくる。しかし、業務全体で運用することを踏まえて考えると、その答えが妥当とは限らない。

審査業務は完全にシステムだけで完結するものではない。申し込みデータを受け取り、システムがチェックする一方で、情報に不備があれば審査センターというオペレーター部門が入力不備の確認や顧客への電話確認を担う。人による判断が必要な工程も残っている。ここに線を引くのはテックリードの仕事だ、と岡本氏は位置づけた。

なお、ここで扱っているAIはシステムに組み込むAIではなく、CodexやClaudeなど開発時に使うAIの話だ。

AIは何でもシステム内で解こうとする

岡本氏は、AIに設計案を求めるなかで、システム内ですべてを完結させる提案が出てくるケースがあったと振り返る。具体例として2つのケースを挙げた。

1つ目は、システム障害時のリカバリー処理。審査中にシステム的な障害が発生した場合、申し込み内容に不備があるわけではないので、本来はオペレーターが対処すべきかどうかは業務判断で切り分けたい。しかしAIに任せると、業務不備もシステム障害も一律にエラーとして扱い、どちらも自動リカバリーさせようとしてしまう。

2つ目は、本人確認が必要と判断された後のデータ更新。全工程で管理している状態を、審査システム側が後続処理で勝手に上書きしてしまう事象が起きることがわかった。AIから見れば「その項目は上書きするための仕組みがある」ように見えるのだが、業務全体で見ると絶対に触れてはいけないデータだった。本来は詳細設計に落とし込む必要があった暗黙のルールが、AI開発の場で顕在化した瞬間だ。

こうした「誰が更新できるデータなのか」の責任分解は、人がレビューして管理しないと担保できない、と岡本氏は語る。

ミーティングに参加していないAIは同じミスを繰り返す

こうした判断はレビューの場で共有できても、ミーティングが終わると別セッションのAIには引き継がれない。判断の背景が記録されていなければ、別の担当者や新たなAIセッションでは同じ議論を一から繰り返すことになり、同様の問題が再発する可能性がある。

人間なら「前回この人が入ってたから知ってるはず」と過去の会話にアクセスできるが、AIはセッションが変わればコンテキストを失う。ここに手を打つために岡本氏のチームが取り組んだのが、ADR（Architecture Decision Record）による判断記録だった。

何が起きたのか、どういう選択肢があり、どの理由で結論を出したのかを書き残しておくことで、次回の設計判断でも、AIとの会話でも同じ前提から始められる。

禁止事項ではなく判断基準を残す

ADRの書き方には落とし穴がある。岡本氏のチームでは、うまくいかなかったパターンと、うまくいったパターンの両方を経験した。

うまくいかなかったのは、禁止事項を積み上げる書き方だ。「これはダメと言われた」「あれはやめてほしい」を並べていくと、AIの自由度が狭まっていく。せっかくAIが多様な観点から提案してくれる利点を殺してしまう。

うまくいったのは、判断基準を渡す書き方だ。「この状態のときは必ず何かしらの処置が必要」「このステータスは絶対にあり得ないので気をつけてほしい」といった基準を残しておくと、AIも次回以降「ここも怪しいかも」と気づいて指摘してくれるようになる。

「書かないと忘れるし、書きすぎるとAIの動きが悪くなる」。この塩梅こそがADRを運用する肝だ、と岡本氏は結んだ。

答えではなく、答えに至る思考を残す

岡本氏がまとめとして提示したポイントは3つある。

1つ目は、AIの提案を採用するかしないか、システム側で責任を負うかどうかの判断は、テックリードが支える必要があるということ。2つ目は、ADRを残すこと。個人や経験の記憶だけで終わらせると、AIは同じ会話を1から繰り返すことになり、判断のスピードも正確さも上がらない。3つ目は、答えではなく答えに至る思考を残すこと。結果だけを書いたADRは、次の判断で応用が利かない。

審査業務のように自動化できる領域と人が担うべき領域が入り混じる仕組みでは、判断の資産化こそがAI活用の生産性を決める。

続くセッションでは、AIを活用する能力そのものをチームで底上げする方法が語られる。

AIエージェント時代、経験をどう積むかという矛盾

同じリポジトリ、同じドキュメント、同じモデルを与えられているのに、エンジニアが上げてくるアウトプットには優劣が生まれる。AIが実装を書く時代に、エンジニアの差はどこから来るのか。PayPayカードのテックリードが、社内勉強会で試したメタ認知の実験を紹介する。

PayPayカード株式会社
テクノロジー統括本部
システム本部審査債権開発部
テックリード
小野将司（おのまさし）氏

LINE銀行から審査債権開発部のテックリードへ

小野氏は2014年にLINE株式会社に入社し、ニュース事業のシステム開発に携わったのち、LINE銀行プロジェクトを経て2023年からPayPayカードへ。現在は審査債権開発部のテックリードとして部長直下に所属し、途上審査、審査刷新、採点システムなど複数領域を横断的に見ている。

ミッションは、PayPayカードエンジニアのレベルを底上げすること

小野氏に降ってきたテーマは「エンジニアのレベルの底上げ」だった。テックリードの仕事には、自分がプレイヤーとして技術を示す役割と、全体を底上げする役割の2つがある。今回は後者のミッションを任された。

しかし、そもそもいまどきの「エンジニアのレベル」とは何を指すのか。小野氏によれば、実装の多くをAIが支援できるほどコード生成の精度が高まっており、自らコードを書く機会が以前より減っているエンジニアも少なくないという。

理想をいえば、全員が同じAIを使えるのであれば差は生まれないはずだ。しかし実際には、同じプロジェクト、同じリポジトリ、同じドキュメント、同じAPI仕様、同じモデル（たとえばClaude 3.5 Sonnet）という条件がそろっていても、成果物には優劣が出てくる。小野氏は「この差がどこから生まれるのか」について考えることから始めた。

プロンプトと対話に、エンジニアの判断は隠れる

その差を生んでいる要因を絞り込んでいくと、明示的なサインとして残るのは「プロンプトと対話」の部分だけだ、という結論に至る。ツールの差は社内制限があるためあまり出ない。誰がどのようにプロンプトを組み立て、AIと対話しているかに、エンジニアの判断と入力の質が表れるという。

小野氏によれば、かつてはソースコードそのものにエンジニアの判断が表れていたという。他人のコードを見て「この人のコードはすごい」「これはおかしいのでは」と感じた経験を持つエンジニアは少なくないだろう。しかし現在はAIエージェントが間に入るため、エンジニアの判断がプロンプトに吸収され、成果物からは見えにくくなっている。ここに、以前との違いがあると小野氏は指摘する。

さらにここで、当時のGPT-4.5に相談してみたという。返ってきたのは「AIに仕事を渡す設計能力そのものをチームの共有財産にしていく必要がある」というフレーズだった。このフレーズをヒントに、小野氏は育成方針を固めていった。

AI自身にレビューさせる仕組みを試した

最初に手がけたのは、AI自身にセッションを振り返らせる「SKILL.md」の仕組みだった。ユーザーからどんな質問が来たか、何が食い違ったか、どの情報を最初に渡してほしかったか。それらをAIに自己申告させて共有できれば、判断の質を底上げできるのではないかと考えたという。

実際にやってみると、AIはたくさんの気づきを返してくれた。事前の情報が足りなかった、コンテキストが間違っていた、ソースコードのここに誤りがあると教えてほしかった、といった具体的な指摘だ。

一方で、実装上の限界も見えてきた。まず、レビューを作る側の手間が大きいこと。毎回コマンドを手で叩き、結果をGitに貼り、レビュアーが目を通すというフローでは、いずれ運用が破綻すると小野氏は感じたという。さらに、レビューする側にも課題があった。事象が間違っていることは分かっても、なぜそう判断したのかまでは踏み込めず、指摘が具体化しないという問題だ。

とはいえ副産物として、良い事例と悪い事例が積み重なった。この積み重ねが次のヒントにつながる。

AIエージェント自身に経験を蓄積させる

次に小野氏が着目したのは、AIエージェント自身に経験を蓄積させるアプローチだ。参考にしたのは、AIがフックを介して日次の業務日誌を自動生成する「JOURNAL.md」の取り組みや、ちょっとしたミス（Paper Cut: 紙で指を切るような小さな失敗の意）をエージェントに自動記録させるXで話題になった手法だ。

彼自身、新人時代につけていた業務日誌にはあまり価値を感じていなかったというが、AIに書かせてみると意味合いが変わってきたという。価値があるのはジャーナルそのものではなく、そこに含まれる「なぜAIがこう判断してうまくいかなかったか」という部分だ。そこだけを抜き出せば、次の会話で再利用できると考えた。

こんな出来事もあったという。小野氏がⅩの投稿を参考にするようエージェントに指示したところ、意図しない方法をAIが選択した。やめるよう指示すると、AI側には「なぜ止められたのか」が伝わらない。しかし、このやり取りそのものがADR的な記録の素材として最適だと気づいたという。こうしたやり取りを自動で蓄積できる仕組みがあればと、小野氏は考えた。

メモリの再発見と、ファイルベースの実用性

さらに調べていくと、このアプローチは実は7月に発表された論文でAIエージェントの長期記憶として整理されている考え方だったことが分かったという。メモリ機能自体はCodexやClaude Codeにも実装されているが、小野氏はこれまで使わずにオフにしていたという。AIが小野氏の意図に合わないコードを勝手に作ってしまうことがあったためだ。

一方で、考え方自体は正しいと小野氏はみている。AIエージェントが過去の経験から自己更新していく情報の仕組みがあればよい。過去にはこれをベクトルDBやナレッジグラフで実装しようとする動きもあったが、あまりに大掛かりで陳腐化も早く、現場ではなかなか浸透しなかったという。

そこで行き着いたのがファイルベースの手法だ。マークダウンで業務日誌形式に書き溜めていけば、自分たちでも検索でき、量も1年で数万行程度に収まる。この規模なら検索は一瞬で済み、人間も読める。遠回りをした末に、「ベクトルDBやナレッジグラフを組む必要はない」という結論にたどり着いたという。

5年後に生き残る「メタ知識」とは何か

まとめとして小野氏が伝えたのは2点だ。1つは、AIエージェント自身にユーザーを評価させたり記録させたりする仕組みはすぐ使えるので試してほしいということ。もう1つは、それ以上に重要となる「メタ的な視点」だ。

小野氏によれば、Claude Codeの使い方や、JOURNAL.mdを書かせる便利さといった個別のノウハウは、早ければ3ヶ月以内に陳腐化してしまう。たとえばClaude Codeがユーザーカスタマイズ可能なファイルメモリー機能を近くリリースすれば、いま使っているツールや工夫はすぐに不要になりかねない。

しかし「どうしてそれが使えるのか」「どうしてそれが便利なのか」というメタ知識は長く生きる。この経験からこれは使える、という判断軸を持つこと。それを発見してチームに教えるのが、これからのテックリードの仕事だと小野氏は語った。

次のセッションでは、こうしたAI活用を組織的に広げているPayPayカード審査債権開発部の体制と文化が紹介される。

AI活用が進む開発組織の裏側とテックカルチャー

金融系だからAI活用は進んでいないのでは、という先入観を持つ人は少なくない。しかしPayPayカード審査債権開発部では、AI駆動開発を検証しながら本格導入を進めており、勉強会やハッカソンなど組織的な学習文化も根付いている。PayPayカードの部長が語る、組織構成とAI活用の現在地に迫る。

PayPayカード株式会社
テクノロジー統括本部
システム本部審査債権開発部
部長
橋村達也（はしむらたつや）氏

製造業からPayPayカードへ、部長として審査債権を統括する

橋村氏は2011年に製造業の社内SEとしてキャリアをスタート。約8年間、工場の配線からPCのキッティング、ソフトウェア開発まで幅広く経験した。その後、通販事業の会社で業務システムやECサイトの開発、プロジェクト推進を担当。2024年にリファラルでPayPayカードに入社し、債権システムを中心に対応してきた。

2025年からは債権管理システムのマネージャーとして活動し、2026年4月からは領域が広がって審査債権開発部の部長に。現在は審査と債権領域のシステム開発組織を統括している。

コーディング以外にも広がるAI活用

PayPayカードの現場で使われているコーディングツールは、Codexが主流。Claude CodeやGitHub Copilotも人によって使い分けられている。実装、レビュー、MCPサーバー（Model Context Protocol サーバー: AIと社内ツールをつなぐ仕組み）を立てたデータ集約など活用領域は広い。チームによってはFigmaデザインからのコード自動生成にも取り組んでいる。

コーディング以外では、ChatGPT、Gemini、NotebookLMなどを日々の調べ物や簡単なシェルスクリプト生成に使う。橋村氏自身は議事録も最近ゼロから開いて書き始めることが減った。資料のたたき台をテキスト要約ツールに入力し、議事録の初稿を作らせるスタイルに変わってきているという。

週次LTと月次AI Agent Dayが支える横断的な学び

PayPayカードのテックカルチャーで橋村氏が3つ紹介したのが、四半期に1回のハッカソン、ナレッジ専用のSlackチャンネル、そしてエンジニアLTだ。

ハッカソンは有志チームで自主的に組んで参加する形式で、PayPayカードだけでなくPayPayグループ全体で開催されている。前回はPayPayカードのチームが賞を獲得したという。

ナレッジ専用のSlackチャンネルには技術的な情報が集約されている。AIのモデルアップデート、他社事例、面白いリンクなどが日々流れてきて、自分一人ではキャッチアップしきれない情報の入り口になっている。

エンジニアLTは毎週木曜日に30分ほど実施されている。各チームが何をしているか、どんなドメインの業務があるか、どうAIを使っているかを共有する場だ。前段で紹介された小野氏のAIレビューの取り組みも、ここで発表された内容の1つだった。

AI活用は劇的なテーマではなく、業務の隣にある

橋村氏は締めくくりに、社内勉強会で扱われている直近のテーマを紹介した。AWS Summitのレポート、リリース承認レビューの改善、AIレビューの記録の仕方、Codexオートメーションを使った開発外業務の効率化など。特別なテーマではなく、実務の隣にあるものばかりだ。

AIの変化は速い。だからこそ、他チームで実践されている使い方を参考にしながら、自分たちの現場に持ち帰る仕組みがあることの価値は大きい。

続くQ&Aセッションでは、金融ドメインでのAI活用の壁、ADRの運用、5年後のエンジニア像といった、より踏み込んだ質問が飛び交うことになる。

Q&A セッション

Q. 金融系というお堅いイメージだが、PayPayカードでのAI活用のハードルはどうですか？

小野氏: 正直、堅いと思う時は全然あります。無尽蔵に使えるかというとそうではありません。ただ常識的な制約の中だと個人的には思っています。なんでもかんでも禁止というわけではないですし、そうはしたくないと考えています。ただ、お客様の個人情報を扱う領域なので、100%自由に使わせてくださいというのはさすがに違うと思っています。決定部門もそのなかでツールを選定していると理解しています。

橋村氏: 金融系なので入れる際に手順を踏むぶんスピード感は落ちますが、思ったより使わせてもらっているというのが私の感覚です。使える限りは使い倒したいと思っています。

Q. ADRは膨大な数になりそうだが、AIはちゃんと読み取れるのでしょうか？

岡本氏: いまのところ、読み取れないという事象は発生していません。AIを本格的に使い始めたのが審査刷新プロジェクトの中盤から終盤なので、膨大な量を扱ったことはまだありません。今後どうなるかは私も気になっています。

Q. ナレッジを残させるにはどうすればよいのか。

橋村氏: PayPayカードでは全社的にAIを活用して、人を増やさずに自動化しよう、というのが各社員に問われています。そのなかで自分ならどう自動化・効率化するかを各自が考えていて、エンジニアと同じく持ち寄って共有しているイメージです。審査の企画で先にやったことを債権の企画にも展開する、といった動きも生まれています。AIを使っているグループと使っていないグループが分かれている、という環境ではないと感じています。

Q. 5年後のエンジニアはどうなるのか？そして後輩へのメタ認知の指導は簡単ではないが、どうすればよいと思いますか？

小野氏: まだ明確な答えはありませんが、この2つはつながっていると思っています。AIで知識を増やすことはできますが、それだけではエンジニアの底上げにはならない。重要なのは、「なんとなくこのコードは危ない」と気づけるようなメタ認知だと思っています。その感覚の正体は、経験です。過去に似たコードで障害を起こしたり、変更に苦労したりした経験が積み重なって、「これは危ない」と直感的に判断できるようになる。5年後のエンジニアに求められるのも、こうした経験に基づく判断力ではないでしょうか。一方で、これからコードを書くのはAIになっていく。自分でコードを書かない時代に、どう経験を積むのかは大きな課題です。現時点では、AIにすべてを任せる前に、人間自身が経験を積むことが重要だと考えています。

以上のやり取りを通じて浮かび上がったのは、AIを使うかどうかではなく、どこまで任せてどこから人が判断するかを組織全体で議論しながら磨き続けているPayPayカードの姿だった。テックリードが引く線、ADRに残す判断、勉強会で共有されるメタ知識。AI時代の開発組織に必要なものが、具体的なエピソードとして浮き彫りになった。

※所属組織および取材内容は2026年8月時点の情報です。