Release:2025.10.31 Update:2025.10.31
2025年秋。ヤマシタのシステム開発部では、介護用品のレンタルや販売を行うホームケア事業の基幹システムリプレイスという⼤規模プロジェクトが進⾏中です。
【前編】 では、基幹システム刷新プロジェクトの背景と、AIエージェントを活⽤した⼤規模コード解析の⼿法について紹介しました。後編となる本稿では、プロジェクトを進める中で直⾯した具体的な課題と、その解決策、そして得られた知⾒や今後の展望について詳しくお伝えします。
苦労したこと
中川:やはりスムーズにはいかない部分もあったと思います。どんな苦労がありましたか?
菅:最も苦労したのは、Playbookの品質向上でした。
初期のPlaybookには2つの問題がありました。まず、解析範囲が浅く、抽象的なサマリに終始してコード根拠の紐付けが弱かった。次に、指定外のリポジトリを参照してしまい、調査の⼀貫性が崩れるケースも発⽣しました。そのため5~6個没となったPlaybookがありましたね。
これらの問題を解決するため、何度も試⾏錯誤を重ねました。最終的に以下のガイドラインを明確にして内容をアップデートしました:
1.リポジトリ‧ガードレール:WhitelistとBlacklistを明⽰
2.エビデンス‧ファースト:各主張に必ず根拠(ファイルパス‧関数名‧抜粋
⾏‧DDLの列)を付与
3.深さの定義:画⾯→コントローラ/Action→API/フォームのI/ODB CRUD列レベル→横断依存の4層を必須化
4."不明"の許容:推測は禁⽌し不明箇所はUNKNOWNでマーク
5.出⼒合格基準:チェックリストで80点以上を必須化
最終的に、チェックリスト付きの採点システム(80点以上で合格)を導⼊することで、安定した品質の解析結果を得られるようになりました。
## やりたいこと
与えられたスクリーンショットを使って、画像に映る内容からコードの解析を⾏いたい。
結果は**Markdown**で出⼒。**ファイル名は英語**、本⽂は⽇本語。
## コンテキスト
既存基幹システムの内製化とリプレイスのため、画⾯とコードを照合して実装とデータ流れを把握したい。
## 使うリポジトリ(Whitelist)
- `@GitHubOrganization/介護事業システムリポジトリ`
- `@GitHubOrganization/⽣産‧販売管理システムリポジトリ`
## 参照禁⽌(Blacklist)
- CRMのバックエンド、フロントエンド ## インプット
- 必須:スクリーンショット、画⾯名or機能名
-任意:基本設計Excel(`項⽬定義(画⾯)`、`機能詳細(画⾯)`)
## やること
1.画⾯→⼊⼝(Controller/Action/Bean)特定
2.API/フォームI/Fの⼊⼒‧出⼒を**実コード根拠**つきで列挙
3.呼び出し鎖(最⼤3ホップ)の**関数名**を追跡
4.DB CRUD(列)をDDL抜粋で提⽰
5.横断参照(介護事業システム↔⽣産‧販売管理システム)の有無と⽅式
6.`UNKNOWN`はそのまま残し追加インプットを要求
## 出⼒
- 冒頭にScope/Whitelist/Blacklistを明⽰
- すべての主張に**ファイル:⾏**の根拠
- 最後に**チェックリスト自己採点**(80点以上でOK、未満なら不足だけ追補して再出力)
中川:AIの出⼒を定量的に評価する仕組みを作ったのは地味ですが、⼤きな成果ですね。
宮内:私の⽅では、⼯数⾒積において⾮常に神経を使いました。
⾃分なりの⼿法を⽤いて⾒積もりは作成できたものの、私がこれまで⼿掛けてきた案件は数千万円規模のものであり、今回はそれを⼤きく上回る規模感でした。
そこで、⼀般的なITベンダーが採⽤している⼿法をAIを活⽤して調査‧理解し、最終的に「拡張的なFP(ファンクションポイント)法」を採⽤しました。
中川:FP法を採⽤した理由は何だったんですか?
宮内:はい、まずは今回採⽤した⼿法について説明し、理由を述べます。今回私が採⽤した⼿法は、FP法をベースに、対応難易度などに応じ係数を加味する、より拡張的な⼿法です。本来でしたら、精度が出やすいとされる類推(アナロジー)法を採⽤したかったのですが、類似の案件に関するナレッジがなかったため、PMBOKやJFPUG(⽇本ファンクションポイントユーザ会)などが公開している参考値により、客観的に⾒積の妥当性を検証が可能な本⼿法を選定しました。
工夫した点としては、AIによる効率化を考慮したことです。外資系コンサルティングファームなどが公開している「AIを使⽤したソフトウェア開発業務の効率化に関する調査結果」を参考とし、AIの適⽤によって効率化が⾒込める分野を選定しました。その上で、対象範囲に効率化係数を適⽤し、⾒積もりを算出しました。
結果として、今回FP法によって導いた⾒積は、国内的‧国際的にも⼤規模システム開発で妥当な範囲である⼯数と裏付けもされた⾒積を導くことができました。国際的に広く使われる⾒積⼿法を採⽤することによって、経営層が判断する際の⼗分な根拠を提供できたと考えています。
中川:初めての⼤規模移⾏プロジェクトだったんですよね?
宮内:はい、私⾃⾝、⼤規模な基幹システムの移⾏業務に携わった経験がなかったため、最初の進め⽅は⼿探りでした。どのような⼿順で進めるのが最適なのか模索しながら、最終的に求める成果物にたどり着けたのは⼤きな学びでした。
個⼈的な取り組みですが、NoteBookLMを活⽤してIPA(情報処理推進機構)が公開しているシステム移⾏関連の⽂書を読み込ませ、⾃作ポッドキャストとして関連知識を学習するなど、⽇々の知識の吸収にも⼯夫を凝らしました。
得られた知⾒
中川:このプロジェクトを通して、どんな気づきや学びがありましたか?
宮内:AIソフトウェアの活⽤が、⽇々の業務の⽣産性に与える影響の⼤きさをあらためて実感しました。
⼈の⼿で数⽇かけていた調査解析の単純作業を、AIが数分で精度よく処理していく様⼦を、プロジェクト中の様々な作業で⽬の当たりにし、まさに時代の変化だと思いました。これは、2, 3年ほど前では考えられない環境です。
AIをどのように活⽤して⽣産性を⽣み出すかが極めて重要であり、AIによる効率化が図れる対応業務と⾮対応業務を明確に分けて考えることで、業務のスピードと精度を⾶躍的に⾼められると感じました。
中川:技術者としての視点から、どう考えますか?
宮内:私⾃⾝、情報⼯学のバックグラウンドを持つ技術者として、当該領域に関することであれば、⼀定の知識さえ得られれば、⾼度な専⾨家レベルでなくとも、ある程度対応できる⾃負があります。
AI対応‧⾮対応業務を分別し、⼈間はAIにより、知識の収集をいかに効率化するか。これらは、AI時代における仕事をより効率的に⾏うためのキーファクターではないのだろうか、と私は考えます。
菅:私は「画⾯ベースでのソースコード解析」が想像以上に効果的だったことが⼀番の発⾒でした。
ユーザー視点で重要な処理から解析できるので、ビジネス価値に直結します。不要な"死んだコード"に時間を費やさず、リプレイスの優先順位付けが圧倒的に楽になりました。
どの画⾯がどのコードに依存しているかが⼀⽬瞭然になったので、「この機能から移⾏すれば影響が少なさそう」とか「ここは最後に回そう」といった判断が、根拠を持ってできるようになったんです。
中川:スピード⾯での成果はどうでしたか?
菅:普通なら180万⾏のコードを全部読もうとしたら、どんなに頑張っても数ヶ⽉から半年はかかると思います。それが約1ヶ⽉で完了できたということは「すべてのコードを理解しなければいけない」という、ある種の呪縛から解放されたからこそ実現できたものだと思っています。
また、AIに明確なガードレールを設けることで、再現性のあるナレッジ化が可能になったのも⼤きな収穫です。曖昧な指⽰を出すと、やっぱり曖昧な結果しか返ってこない。ですが、厳密な制約と「必ず根拠を⽰せ」という要求を設定することで、⼈間のレビュー⼯数を⼤幅に削減できることがわかりました。
今後の展望
中川:最後に、今後の展望について教えてください。この取り組みをどう活かしていきますか?
菅:今回確⽴したAI解析⼿法とPlaybookは、⼀度限りのものではなく今後の移⾏全体を⽀える仕組みです。
具体的にどう活⽤していくかというと、まずAPIとバッチを使い分けながら、部分的に移⾏を進めていきます。例えば、リアルタイム性が必要な機能はAPIで、⼤量データの処理はバッチで、といった具合です。
参照が多い領域は後回しにするなど、リスクを抑えつつ、2027年の保守期限に間に合わせる計画です。期限までに確実に移⾏を完了させながら、同時に早い段階からビジネス価値を出していく。このバランスを取りながら進めていくつもりです。
中川:この⼿法は他のシステムにも応⽤できそうですか?
菅:はい、今回確⽴した「AIエージェントを活⽤した⼤規模コード解析」の⼿法は、実は他のシステムにも応⽤できるんじゃないかと思っています。当社には他にも基幹システムがありますし、将来的に技術的負債を解消する必要が出てきたときにも、この⼿法が使えるはずです。
特に良いなと思っているのは、Playbookの再現性です。属⼈化せず、ナレッジとして残せるのが最⼤の価値ですね。私がいなくなっても、このPlaybookがあれば、次の担当者も同じ品質で調査ができる。これって組織としてのナレッジ蓄積という意味でも、すごく価値があることだと感じています。
宮内:基幹システムの移⾏は地味で⼿間のかかる印象がありますが、当社の取り組みは⼀味違います。今回の計画の特徴は、外部のベンダーに依存せず、内製化によって根本からシステムを刷新していく点にあります。
単なる機能の移⾏に留まらず、業務設計そのものを⾒直し、事業オペレーション全体をソフトウェアで最適化するという挑戦です。
中川:実際に現場からの反応はどうですか?
宮内:現場の声を直接反映しながら開発を進められることが⼤きな魅⼒です。実際、今年夏頃にリリースした、先⾏的に特定機能のみをリプレイスしたシステムにおいては、現場の皆さまより好評の声が届いています。ありがたいことです。
今後も、現場の皆さまとより密に連携をとらせていただき、利⽤者のリアルな声を起点に、現場に寄り添うシステムづくりを推進していきます。
中川:お⼆⼈の取り組みは、まさに「AI時代のエンジニアリング再定義」と⾔えそうですね。
宮内:AIの精度を最⼤化するための設計思想が、これからの開発者に求められるスキルだと感じました。すべてを⾃動化できるわけではなく、AIが得意な部分をどう切り出すかが重要です。
AIに任せられるところは⼤胆に委ね、⼈間は意思決定と精度検証に集中する。この分業がとても効果的でした。
菅:今後もこの⼿法をブラッシュアップしていって、もっと効率的で、もっと精度の⾼いシステム移⾏を実現していきたいと考えています。
おわりに
外部委託から内製化へ──その変化は単なる構造転換ではなく、エンジニアが主導する新しい"知の再構築"でもあります。
180万⾏という途⽅もない規模のコードベース。わずか2名、2ヶ⽉という制約。
2027年に迫る保守期限。これらの困難な条件を前に、宮内さんと菅さんは、AIエージェントを戦略的パートナーとして迎え⼊れ、従来の常識を覆すアプローチで挑戦を続けています。
「全てのコードを理解する」という呪縛から解放され、「ビジネス価値のあるコードから理解する」という新しい⽅法論。AIに明確なガードレールを設け、エビデンスファーストで進める品質管理。そして、属⼈化を防ぐ再現性のあるナレッジの構築。
彼らの挑戦は、単にシステムを移⾏するだけでなく、これからのエンジニアリングのあり⽅そのものを再定義しているのかもしれません。
地道な技術の積み重ねと新しい発想が融合したこのプロジェクト。ヤマシタがテクノロジーで社会課題を解決する企業へと進化していく、その象徴的な取り組みがここにあります。