人間とAIの「言葉のずれ」を解消する — gaipack セマンティック APM プラグインのご紹介

開発の現場で頻発する「言葉の定義が揃っていない」問題を解消するために、オントロジー定義スキル「gaipack セマンティック APM」プラグインを作成しました。本記事では、オントロジーの考え方とプラグインの使い方を整理してお伝えします。

こんなこと、ありませんか？

開発の現場では、次のような課題が日常的に発生しています。

• 定義の曖昧さ: 「売上金額」が税抜きなのか税込みなのか、毎回確認が必要になる
• 機能の重複: 実装した機能が、別のPRDですでに実装済みだったことに後から気づく
• 人間とAI間の認識のずれ: 同じ「会員」という言葉でも、人によって、あるいはAIとの間で指すものが異なる

これらに共通する根本原因は、正しい意味が1箇所に定まっていないことです。

オントロジーとは

オントロジーとは、ある分野の概念と概念同士の関係を、人間にもAIにも理解できる形で明示的に定義したものです。

正しい仕様を1箇所にまとめ、人間もAIも同じ言葉・同じ構造で共有できるようにすることがオントロジーの狙いです。

オントロジーがあると何が変わるのか

先ほどの3つの課題に対して、それぞれ次のように解消が期待できます。

gaipack セマンティック APM プラグイン

オントロジーの定義と活用を支援するプラグインとして、gaipack セマンティック APM を gaipack スキルマーケットプレイスに用意しています。APM 経由でインストールが可能です。

プラグインの構成

プラグインは大きく2つの要素で構成されています。

1. セマンティックオントロジー（スキル）

オントロジーを定義するためのスキルです。対話形式で定義を進め、プロジェクトのルートにオントロジーフォルダーを作成します。出典禁止・推測禁止・承認の3原則で品質を守り、検証や生成のツールも備えています。

2. フック

定義したオントロジーを利用するための仕組みです。セッション開始時に自動で起動し、オントロジーの入り口情報をコンテキストに自動注入します。注入されるのはブートストラップ情報のみのため、トークンを大きく消費しない設計になっています。

つまり、定義するスキルとそれを使うフックが1つのプラグインにまとまっている構成です。

オントロジーの4要素

本プラグインでは、オントロジーを4種類の要素に分けて管理します。

この4要素がまとまって、1つのオントロジーを構成します。

導入から利用までの3ステップ

ステップ 1: インストール

APM 経由で gaipack セマンティック APM をインストールします。オントロジーを作るための方法論とツールがエージェントに追加されます。

ステップ 2: オントロジーフォルダーの生成

スキルが入っている環境で「○○についてオントロジーを定義したい」と伝えるだけで開始できます。オントロジーフォルダーの作成から構成ファイルの生成まで、スキルが自動で処理します。生成されたフォルダーはチームでコミットして共有します。

対話形式でエンティティや関係を追加していく流れで、AIが勝手にファイルを書き換えることはありません。追加する内容を提示し、ユーザーが承認した内容のみがファイル化される仕組みです。

ステップ 3: 自動適用

プラグインのフックがセッション開始時にオントロジーの構成情報を自動でコンテキストに注入します。これにより、人間もAIもセッション開始時から同じオントロジーを土台にして開発を進められます。

実際の出力例：「売上金額」の定義

「売上金額のオントロジーを定義して」と伝えた場合の出力例を紹介します。

ディレクトリ構成

ontology/
├── entities/
│   └── sales_amount.yaml
├── relations/
│   └── ...
├── actions/
│   └── ...
└── functions/
    └── sales_calculation.yaml

エンティティの例（sales_amount）

売上金額のエンティティには、ID・名称・別名・関係先・出典、そして「税抜きの売上合計」といった定義が記述されます。

ファンクションの例（sales_calculation）

売上計算のファンクションには、次のようなルールが明文化されます。

• 売上金額 = 単価 × 数量の合計 × 割引率
• 税抜きで計算する
• 割引は一括適用
• 端数は切り捨て

このように定義がファイルとして残るため、人間もAIもいつでも同じ定義を参照できます。

誰がオントロジーを定義すべきか

オントロジーの定義はエンジニアだけの仕事ではありません。むしろ PRD（プロダクト要求仕様書）を作る前、あるいは作りながら並行で定義していく のが効果的です。

PM（プロダクトマネージャー）や要件定義チームが早い段階で言葉を揃えることで、次のような効果が期待できます。

• 後工程での仕様のずれを防止できる
• 概念を洗い出す過程で、PRDに定義が漏れている項目が見えてくる
• 複数のPRD間で整合性を保つことに役立てられる

DDDのユビキタス言語との関係

オントロジーの話をすると、ドメイン駆動設計（DDD）における「ユビキタス言語」との違いが気になる方も多いのではないでしょうか。

両者は非常に近い考え方であり、概念と用語を統一してチーム全体で共有するという目的は共通しています。オントロジーはこれをファイルとして構造化し、AIにも読み取れる形にすることで、人間同士だけでなく人間とAIの間の共通言語としても機能する点が特徴といえます。

まとめ

本プラグインは社内で継続的に改善を進めています。gaipack では、このようなオントロジー定義による用語統一や、人間とAIの認識共有の仕組みづくりを支援しています。ご興味のある方は、お気軽にご相談ください。