AIコーディングツールを導入したのに効果が出ない会社には、共通する事情がある。自社の基幹システムが、世の中に公開情報のない独自フレームワークや社内共通部品の上に載っていることだ。その部分の情報がAIに渡っていなければ、一般的な作法を当てはめた回答が返り、誤答になる。そして基幹システムの改修は、たいていその部分を触る作業である。
TISIは2026年8月6日、Java業務アプリケーション開発・実行基盤「Nablarch」のナレッジをAIコーディングツールから参照できるプラグイン「Nabledge」を公開した。GitHub上で提供されており、ライセンスはApache-2.0である。
このプラグインは、Claude CodeおよびGitHub Copilotのスキルとして追加できる。公開されているリポジトリの記述によれば、開発者に代わってコード解析、ドキュメント検索、影響調査を行うためのAIエージェント向けナレッジベースと位置づけられている。導入はプロジェクトのルートでセットアップ用スクリプトを実行する形をとり、Nablarchの複数のバージョン系統に対応したプラグインが用意されている。
報道によれば、この取り組みの背景には、金融・公共分野の基幹系システム開発において、AIコーディングツールの利便性を生かしきれていない状況があり、Nablarch特有の実装方法についての誤回答を抑制する狙いがあるとされている。なおTISIは、2026年7月にTISとインテックが合併して発足した会社である。
Nablarchを使っていなくても、この取り組みから持ち帰れるものがある。自社の基幹システムが独自の作りになっていて、AI活用の話になるたびに「うちは特殊だから」で止まっている会社にとって、ここには具体的な手順が示されている。
この記事を読むべき人
- 10年以上運用している業務システムを持ち、社内共通部品や独自の作法が積み上がっている会社
- AIコーディングツールを導入したが、開発の速度がほとんど変わっていない会社
- 開発会社から「AIを活用するので工数が下がります」と提案されたが、検証方法が分からない会社
- システムの中身を説明できる人が1〜2名に集中している会社
- 内製化を進めたいが、既存システムの学習コストが壁になっている会社
MANUFACTURING DX
Excel限界から受発注システムへ、同規模の概算は？
中小製造業の概算費用・導入期間・役割分担マトリクスをその場で確認。要件整理テンプレも無料提供します。
なぜ独自フレームワークだとAIが誤答するのか
正確に言えば、AIコーディングツールは公開情報しか使えないわけではない。許可されたリポジトリ、ファイル、指示、検索結果などを文脈として読み込める。問題は使える情報の種類ではなく、プロジェクト固有のコード、設計資料、規約、依存関係が十分に渡されていないことにある。必要な文脈が欠けたとき、AIは「分かりません」と言うとは限らず、一般的な実装パターンに寄った回答や推測を返す。それが誤答になる。
具体的に、自社システムのどこがこれに当たるかを整理すると次のようになる。
横にスクロールして確認できます
| 自社にしかない情報 | AIが代わりに当てはめるもの | 結果として起きること |
|---|---|---|
| 社内共通部品の使い方 | 一般的なライブラリの使い方 | 動かない、または規約違反のコード |
| 独自の命名規則・レイヤ構成 | 一般的な命名・構成 | レビューで差し戻し |
| 過去の障害から生まれた禁止事項 | 一般的な実装パターン | 同じ障害を再発させる書き方 |
| 業務上の例外ルール | 標準的な業務ロジック | 仕様と合わない実装 |
| どのモジュールがどこに影響するか | 推測 | 影響調査の漏れ |
**この表の右列が、AI導入後に「かえって手戻りが増えた」と言われる状態の正体である。**生成されたコードのレビューに時間がかかり、書き直す手間が上乗せされる。速くなるはずが遅くなる。
しかも厄介なのは、この状態が数字に現れにくいことだ。AIツールの利用回数は増えているので、導入は成功しているように見える。開発者は「使ってはいる」と答える。だが実装のリードタイムは変わらず、レビュー担当の負荷だけが上がっている。経営がツールの利用率だけを見ていると、この状態を発見できない。確認すべきは利用率ではなく、レビューでの差し戻し率がどう変化したかである。
Nabledgeが解こうとしているのは、この表の左列をAIが参照できる形で渡すという課題である。フレームワークの提供元が公式のナレッジとして整備し、AIツールのスキルとして読み込ませる。利用企業から見れば、自社で用意しなくても左列の一部が埋まることになる。
自社に置き換えると、何を用意する話になるか
ここからが本題である。自社の基幹システムが特定のフレームワーク製品ではなく、社内で育った独自の作りである場合、公式のナレッジは存在しない。用意するのは自社である。
ただし、いきなり全部の設計書を書き直す話ではない。AIに渡して効果が出やすい情報には優先順位がある。効果の大きい順に並べると次のようになる。
第一に、規約と禁止事項。「この共通部品を使うこと」「直接データベースに接続しないこと」「この関数は非推奨で、代わりにこれを使うこと」といったルール。**分量が少なく、効果が最も大きい。**AIが最も外しやすいのがここであり、しかも文章にしやすい。
**第二に、典型的な実装パターン。**画面を1つ追加するとき、帳票を1つ増やすときの標準的な手順とコード例。既存のコードから代表的なものを2〜3本選んで「これが標準形」と示すだけでよい。
**第三に、モジュール間の依存関係。**どの部品がどこから呼ばれているか。影響調査の精度がここで決まる。全体を網羅する必要はなく、変更頻度の高い領域から始める。
**第四に、業務ルールの背景。**なぜこの処理が必要なのか、どの法令や取引先要件に由来するのか。分量は多くなるが、これがないと「不要に見えるコード」を削除する提案が出てくる。
**そして最後に、詳細設計書。**優先順位が最も低い。網羅性を求めると作成に何か月もかかり、その間に実装とずれる。
多くの会社が、この順序を逆から始めて挫折している。「AIを使うにはドキュメントを整備しないと」と考えて詳細設計書から着手し、分量に圧倒されて止まる。実際には、第一の規約と禁止事項だけをA4数枚にまとめるところから、目に見える効果が出る。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
ドキュメントが一切ない会社は何から始めるか
「規約も文書化されていない」という会社は珍しくない。その場合の着手点は、書くことではなく聞き出すことである。
システムを理解している人に対して、次の質問をする。回答をそのまま文章にすれば、第一段階の資料になる。
- 新しく入った人が最初に間違えるのは、どこか。
- コードレビューで、毎回同じ指摘をしている項目は何か。
- 「これだけは触るな」と伝えている箇所はどこで、それはなぜか。
- 過去に大きな障害を起こした変更は何で、その後どういうルールを作ったか。
- 同じ処理を書く方法が複数あるとき、どれを選ぶことにしているか。
- 外部の会社に依頼するとき、必ず説明することは何か。
**この6問の答えは、そのまま「AIに渡すべき情報」であり、同時に「新入社員や新しい外注先に渡すべき情報」でもある。**つまりこの作業は、AI活用のためだけの投資ではない。属人化の解消と、引き継ぎの準備を兼ねている。
聞き取りの進め方にも注意点がある。**質問する側が技術を理解している必要はない。**むしろ理解していないほうが、相手は前提を省略せずに説明してくれる。録音して文字に起こし、後から整えるだけでよい。所要時間はシステムの規模と回答者の人数で変わるため、まず1回分の枠を確保して実施し、そこから見積もり直すのが早い。完璧な聞き取りを目指すより、まず1回やって形にすることを優先したほうがよい。1回目の資料を関係者に見せると、「ここが抜けている」という指摘が出る。その指摘が2回目の質問リストになる。
ここが重要な点だ。**AIのためにドキュメントを作るという名目は、これまで先送りされてきた属人知の可視化に予算をつける口実になる。**多くの会社で、引き継ぎ資料の整備は「重要だが緊急ではない」ため何年も後回しにされてきた。AI活用という現在の関心と結びつけることで、ようやく着手できる。
「AIが読める形」とは具体的に何か
抽象的に聞こえるので、実務的な形に落としておく。特別な仕組みは要らない。
**置き場所は、ソースコードと同じ場所がよい。**設計書がファイルサーバーの奥にあり、コードがリポジトリにあるという分離状態だと、AIツールからも人からも参照されにくい。コードと同じリポジトリに、テキスト形式の文書として置く。Nabledgeもプロジェクトのルートにセットアップする形をとっている。
**形式は、装飾のない書式付きテキストでよい。**表計算ソフトの表や、図が主体の資料は、機械にとって読み取りにくい。箇条書きと短い見出しで書かれた文章が最も扱いやすく、しかも人間が読むときにも速い。
分量は、1テーマ1ファイルに分ける。「規約」「実装パターン」「禁止事項」「業務ルールの背景」を1つの巨大なファイルにまとめると、必要な部分だけを参照させにくくなる。
**更新の責任者を決める。**ここが抜けると、半年後には実装と文書がずれる。ずれた文書は、渡さないより悪い。誤った情報でAIが自信を持って誤答するからだ。**現実的な運用は、コードを変更したときに同じ変更のなかで文書も直す、という形にすることである。**別作業にすると必ず後回しになる。
この4点は、AIのための特別な作業ではなく、まともなドキュメント管理そのものである。**AI活用を機に整えたものは、AIを使わなくなっても価値が残る。**逆に言えば、AIのためだけに使い捨ての資料を作るのは投資として弱い。
整備が形骸化する3つのパターン
ナレッジ整備に着手した会社が止まる場所も、だいたい決まっている。
パターン1：網羅性を求めて終わらない。「全機能の仕様を書き切ってから」と考えると、規模によっては年単位になる。その間、効果はゼロのままである。改修頻度の高い領域から部分的に始め、使いながら足す形にしないと完走しない。
**パターン2：作ったが更新されない。**初回は予算がついて整備できるが、以後の更新に人が割かれない。前述のとおり、コード変更と同じ作業のなかで直す運用にしておかないと、必ずこうなる。
**パターン3：現場が読まない・使わない。**整備を外部に委託し、成果物を受け取って終わりにすると起きる。書いた人と使う人が違うと、書かれている粒度が現場の必要と合わない。少なくとも最初の1本は、実際に開発している人が書くか、その人へのヒアリングをそのまま起こす形にしたほうがよい。
この3つに共通するのは、整備を「プロジェクト」として扱うと失敗し、「日常の作業手順」に組み込むと続くという点である。経営としては、初期の整備に予算をつけるだけでなく、以後の更新を通常の開発工数に含める前提で契約を見直すことが必要になる。
「公式ナレッジがあるか」は今後の選定基準になる
もうひとつ、中期的な視点を挙げておきたい。
これまでフレームワークやパッケージを選ぶとき、比較されるのは機能、価格、実績、サポート期間だった。今回のような取り組みが広がると、そこに**「AIコーディングツール向けの公式ナレッジが提供されているか」**という項目が加わることになる。
理由は費用に直結するからだ。公式ナレッジがある製品を選べば、自社で整備する分量が減る。なければ、その差は自社の作業として積み上がる。同じ機能・同じ価格の製品が2つあるなら、この差は無視できない。
自社が今後、新しい基盤やパッケージを選定する場面があるなら、提案依頼の項目に加えておくとよい。「貴社製品について、AIコーディングツールから参照できる形式のナレッジは提供されていますか。提供されていない場合、開発時にどう補うことを想定していますか」。この問いに答えられるかどうかで、提供側がこの流れをどう見ているかも分かる。
「AIを使うので工数が下がります」を検証する
開発会社から、AI活用を理由に工数削減や単価据え置きを提案されることが増えている。この提案が実現可能かを、発注側が判断するための質問を挙げる。
**質問1：AIが有効に働く範囲は、今回の開発のどの部分か。**新規の画面や標準的な処理なら効きやすい。既存の独自部分に手を入れる作業は、前述の理由で効きにくい。今回の案件がどちらに寄っているかで、削減幅の現実性が変わる。
質問2：当社のシステム固有の作法を、AIにどう渡すのか。「これから整備します」なら、その整備工数は誰が負担するのか。「渡さずに使う」なら、誤答のレビュー工数はどこに計上されているのか。
**質問3：生成されたコードのレビュー体制はどうなっているか。**AIの利用によって実装時間が減っても、レビューと検証の時間が増えれば総工数は変わらない。レビュー工数が見積もりに含まれているかを確認する。
**質問4：整備したナレッジは、当社の資産として残るのか。**ここが最も重要である。開発会社が自社の中だけにナレッジを蓄積する形だと、次の案件でも同じ会社に頼まざるを得なくなる。契約上、成果物としてナレッジを受け取れるかを確認する。
質問4は、逆の効果も生む。**自社システムの規約とパターンがAIが読める形で整理されていれば、別の開発会社に依頼するときの立ち上がりも速くなる。**属人知が特定のベンダーの中にしかない状態は、ベンダーを変えられない状態と同じである。ナレッジの整備は、AI活用の準備であると同時に、選択肢を取り戻す作業でもある。
効果が出る領域と、出ない領域を先に分ける
AIコーディングの効果は、対象領域によってはっきり差が出る。投資判断の前に、自社の開発案件がどちらに寄っているかを見ておきたい。
横にスクロールして確認できます
| 効果が出やすい | 効果が出にくい |
|---|---|
| 新規の画面・帳票の追加 | 独自共通部品の内部の改修 |
| 公開されている技術の範囲での実装 | 社内でしか使われていない仕組みの変更 |
| テストコードの作成 | 仕様が文書化されていない機能の改修 |
| 既存コードの読解・影響調査の補助 | 業務ルールの解釈が必要な判断 |
| 定型的なデータ移行・変換の処理 | 過去の経緯に依存した例外処理 |
**この表の右列を左列に移していく作業が、前述のナレッジ整備である。**つまり「AIが使えない領域」は固定されたものではなく、渡す情報を増やせば動かせる。Nabledgeの取り組みは、フレームワーク提供元がその移動を代行した例と読める。
一方で、右列の最下段「過去の経緯に依存した例外処理」は、情報を渡しても完全には移らない。なぜその例外があるのかを判断できるのは、業務を知っている人だけだからである。**AIが担えるのは調査と実装であって、業務上の判断ではない。**この線引きを持たないまま「AIで内製化できる」と考えると、判断が必要な場面で止まる。
経営として決めるべきこと
最後に、この話を投資判断の形に整理する。決めるべきは3点である。
**第一に、ナレッジ整備に人を出すかどうか。**前述の6問に答えられるのは社内の人間だけであり、その人はたいてい最も忙しい。数時間のヒアリングを確保できるかは、経営が決める話になる。ここを現場任せにすると、いつまでも時間が取れない。
**第二に、整備したものを誰の資産にするか。**自社に残すのか、開発会社に預けるのか。**契約に成果物、著作権、利用権、ソースコードと設計資料の引渡し、リポジトリの管理者が明記されていない場合、自社が自由に利用・移管できるとは限らない。**契約書と納品物一覧で、この点を確認しておく必要がある。
**第三に、どこまでを内製に戻すか。ナレッジが整うと、簡単な改修は社内でも扱えるようになる可能性が出る。ただし全部を戻すのは現実的ではない。「調査と一次判断は社内、実装は外部」といった線を先に引いておくと、整備の到達点も決まる。**到達点がないと、ドキュメント整備が終わりのない作業になる。
よくある質問
Q. Nablarchを使っていないので関係ないのではないか。 A. Nabledgeそのものは使えない。ただし「フレームワーク固有の知識をAIに渡すことで誤答を減らす」という考え方は、自社の独自部分にそのまま適用できる。関係があるのは製品ではなく、その手法のほうである。
Q. まず何を作れば、効果を実感できるか。 A. 規約と禁止事項をA4数枚にまとめ、それをAIツールに読ませたうえで、実際に発生している改修案件をひとつ試すのがよい。網羅性より、効果を確認できる最小単位から始めるほうが続く。
Q. ドキュメントを整備すると、その分の工数が増えるだけではないか。 A. 単発で見れば増える。回収できるかは、その情報を何回使うかで決まる。改修が年に数回しかないシステムなら回収は遅く、毎月何らかの改修が発生しているシステムなら早い。回収期間そのものは、整備にかかった工数、改修1件あたりの短縮量、担当者の単価から自社で算出する必要がある。まず改修頻度を確認するところから始めるとよい。
Q. システムを理解している人が既に退職していて、6問に答えられる人がいない。 A. その場合、聞き出す相手をコードに変えることになる。既存コードを読み、繰り返し現れる書き方を「事実上の規約」として抽出する。人に聞くより時間はかかるが、AIツール自体をこの読解作業に使える。ただし抽出されるのは「どう書かれているか」であって「なぜそう書かれているか」ではない。禁止事項の背景は復元できないため、触ってよい範囲の判断は慎重になる。答えられる人がまだ在籍しているうちに聞くことの価値は、この差にある。
Q. 導入手順が外部スクリプトの実行になっているが、そのまま実行してよいか。 A. 公開されている導入手順には、ネットワーク上のスクリプトを取得してシェルで直接実行する形式が含まれる。本番の開発端末で実行する前に、スクリプトの内容を取得して中身を確認し、参照するコミットを固定し、何を書き換えるのかを把握してから実行するのが基本になる。社内方針が外部スクリプトの直接実行を禁止している場合は、その手順を使わず、内容を確認したうえで手動導入する。ここを省くと、開発効率を上げるための導入が供給網側のリスクを持ち込むことになる。
Q. AIに社内の情報を渡すことに抵抗がある。 A. 何を渡すかで分けて考える必要がある。規約や実装パターンは、渡さなければ効果が出ない情報である。一方、顧客データや個人情報は、コード生成のために渡す必要がない。利用するツールがどこにデータを送るか、学習に使われるかは、契約と設定で確認できる。この確認を済ませずに全面禁止にすると、効果の大きい部分まで止まる。
効果が出ない原因を切り分けたいとき
AIコーディングツールを導入したのに開発が速くならない場合、原因はツールの選定ではなく、自社システムの情報がAIに渡っていないことにある場合がある。ただしこれは仮説であって、実際にどこで詰まっているかは、レビューの差し戻し内容と改修案件の実績を見なければ判定できない。
自社システムのどこが独自で、何を先に文書化すれば効果が見込めるかを整理したい場合は、システム開発・DX推進の相談に相談してほしい。既存資産の状態を確認したうえで、整備の優先順位を提示できる。
AI活用の可能性を投資判断の前に評価する場合はAI導入アセスメント、開発や運用のプロセスにAIエージェントを組み込む段階であればAIエージェント導入が該当する。開発会社から受け取った提案の妥当性を第三者の視点で確認したいという依頼も扱える。連絡はお問い合わせから。
参照した情報
- GitHub「nablarch/nabledge」（提供機能、対応ツール、導入方法、対応バージョン、ライセンス）: https://github.com/nablarch/nabledge
- TISI公式ニュース「Nabledge」の公開について（2026年8月6日）: https://www.tisi.jp/news/2026/tisi_news/20260806_1.html
- TISI公式 お知らせ（TISとインテックの合併によるTISI発足、2026年7月1日）: https://www.tisi.jp/news/2026/tisi_info/20260701_1.html
- IT Leaders「TISI、Java開発環境『Nablarch』のナレッジをAIコーディングツールで活用できるプラグイン『Nabledge』を公開」（2026年8月6日）: https://it.impress.co.jp/articles/-/29664
Nabledgeの機能・対応ツール・導入方法・ライセンスは公開リポジトリの記述に基づく。公開日およびTISIの発足（2026年7月1日、TISとインテックの合併）は同社公式ページで確認した。公開の狙いに関する記述は報道による。ナレッジ整備の優先順位、ヒアリング6問、開発会社への確認質問、効果が出る領域の切り分けは、独自資産を抱える発注側企業を支援する立場からGXOが組み立てたものである。TISIおよびNablarchプロジェクトが示した手順ではない。導入にあたっては、公開リポジトリの手順と自社のセキュリティ方針を照らして判断してほしい。
