公開リポジトリの業種別分析で示された「言及」と「起票」の差

GitHubが公開したOctoverse 2026の年次報告では、初めて公開リポジトリを対象とした業種別の分析結果が盛り込まれました。基本集計期間は2025年10月1日から2026年9月30日までの1年間で、業種別の集計は2022年から2026年に作成された公開リポジトリの年別無作為標本を抽出し、リポジトリ名や説明文、トピック、READMEなどのテキスト情報から言語モデルを使って北米産業分類体系（NAICS）の各業種へ分類した推定値です。

この分析で注目されるのは、「AIについて文章中で言及しているか」と「検出可能なエージェントによるプルリクエストの起票があるか」を別々の指標として観測している点です。たとえば、事業上の管理・支援サービス（administrative and support services）、鉱業、医療、農業の各分野では、4割を超えるリポジトリがAIに言及しているのに対し、検出されたエージェント起票のプルリクエストが存在するリポジトリは3%未満にとどまります。一方、建設分野ではAIへの言及は約4分の1であるものの、エージェント起票のプルリクエストは約9%に達し、業種別で最も高い割合として報告されています。

リポジトリの割合を企業の導入率や業務成果と混同しない読み方

「観測指標と実務確認の区分」の表題のもと、「AIへの言及」「エージェント起票」「業務要件の充足確認」の3枠が並び、資料や差分、帳票のモチーフが描かれた図

これらの数値を社内のシステム導入や保守の判断材料にする際には、指標の前提条件を慎重に切り分ける必要があります。まず、この調査の業種別数値は公開リポジトリのみを対象としたものです。非公開リポジトリや一般企業の社内環境全体を反映した統計ではありません。また、特定の産業に属する企業のAI導入率そのものを示す指標とも異なります。

さらに、GitHubが注記しているように、エージェント起票の観測指標はプラットフォーム側で検出できた利用の下限値です。すべてのAI利用を捉えきれているわけではありません。文章内でAIに言及していることと、検出されたエージェント起票という観測指標の間には開きがあります。プルリクエストが起票されたとしても、その変更が業務要件を満たして実用に耐える成果物になったかどうかまでは、この指標からは判断がつかないのが実情です。業界の話題性や言及率の高さだけで自社の導入範囲を決めるのではなく、自社環境で「AIに何を任せ、何を成果物として確認するか」を個別に切り出す視点が欠かせません。

既存保守でAIに渡す作業と確認の証拠　正本参照と帳票確認の事例

内製の AI エージェントツールの概要
引用元：Amazon Web Services

公開リポジトリの指標だけでは見えてこない「既存システムの保守でAIをどう動かし、どう確認するか」について、実案件の工程を示した具体的な記録があります。ニッセイ情報テクノロジーの保守開発事例（AWSブログ）では、個人保険の基幹系システムにおける通知帳票の改修を題材に、内製ツールと開発ワークフローを組み合わせた取り組みが報告されています。

この事例では、AIが一般的な推測でコードを生成しないよう、社内で管理されているコーディング規約やコード表の正本をそのままAIエージェントに参照させる構成をとっています。また、指示ファイルの中で「構文チェックやテストの成否は推測で書かず、ツールが返した実行結果に基づいて記述する」という決まりを徹底させました。さらに、変更結果の確認においては、帳票を画像として出力し、業務を所管する部門が最終的な出力物を目で見て判断できる仕組みを整えています。設計書やコードの差分だけでなく、仕様の正本、実行されたテスト結果、業務担当者が確認できる出力物を揃えることが、既存保守で品質を保つための具体的な手掛かりとなります。

自社の小さな改修から試す　帳票項目追加を想定した検証の組み立て

自社の基幹システムや業務システムにAIを活用する場合も、最初から開発工程全体を自動化しようとせず、影響範囲が限定された一つの改修を対象に試行することが現実的です。たとえば、建設会社の既存工事管理システムにおいて、現場別の作業報告帳票に新しい表示項目を一つ追加する改修を想定してみます。

この場合、まずは現行の帳票仕様と追加したい項目の正本資料、期待する帳票イメージを用意します。AIにはその仕様をもとに変更差分を作成させますが、構文チェックやビルド、単体テストの実行は既存の開発環境で動かし、その実結果を変更履歴に残します。最終的に生成された帳票イメージを担当者が目視で確認し、意図通りに出力されているかを検証して承認する手順です。このように、仕様の正本、AIによる変更差分、ツールの実行結果、担当者の確認記録を一つの改修チケットに対応付けて記録することで、AIの提案精度や確認にかかる負荷を客観的に評価できます。

市販のAI製品をそのまま導入するだけですべての既存ツールと正本が自動連携できるとは限りません。自社のソース管理や課題管理、テスト環境との接続方法、帳票の出力確認をどのように行うかについては、標準設定で進められる範囲と追加の連携設計が必要な範囲を分けて検討する必要があります。

デノフに相談できること

デノフのサービス案内では、Webサイトや社内業務システムの設計・開発・運用保守から、AI導入の業務整理やツール選定、定着支援までを一貫して提供しています。既存の業務システムでAIを活用したいものの、どの保守作業から着手すべきか判断がつかない段階でも、保守工程の棚卸しや対象作業の選定から進めることが可能です。

具体的には、仕様書や社内規約といった正本資料の参照方法、既存の課題管理ツールやテスト環境との接続検討、担当者が目視で確認しやすい確認画面や出力手順の設計など、実務に即した導入範囲の具体化を支援します。ご依頼内容が固まる前の検討段階から、デノフへの相談窓口にてご相談を受け付けています。