AIのためのオンボーディングドキュメントを整備するのトップ画像

AIのためのオンボーディングドキュメントを整備する

投稿日時:
hiroteaのアイコン

株式会社スマートバンク / サーバーサイドエンジニア

hirotea

Xアカウントリンク

本記事では、2025年5月28日に開催されたオンラインイベント「AIエージェントのオンボーディング-ヒトとAIの協同を支える”役割設計”とは」内のセッション「AIのためのオンボーディングドキュメントを整備する」の内容をお届けします。同セッションでは、株式会社スマートバンクのhirotea(@nifuchi222222)さんに、AIエージェントが参照できる共通基盤としての「AIオンボーディングドキュメント」についてお話いただきました。ぜひ本編のアーカイブ動画とあわせてご覧ください。


hirotea:株式会社スマートバンクでAI家計簿アプリ「ワンバンク」というサービスを開発している、hiroteaといいます。
本日の発表は、3月に弊社ブログで公開した記事の内容をブラッシュアップしたものです。

「AIオンボーディングドキュメント」は、使用者に左右されず同じ品質を再現し、あらゆるAIエージェントが参照できる共通基盤とすることを目的としています。

本日は、このドキュメントを「どこで管理し」「どのようにナレッジを込めて配置し」「どう作成・メンテナンスするか」を、皆さんがすぐ実践できるよう、具体的な事例と共にお話しします。

ドキュメントの構造

スマートバンクで作成したAIオンボーディングドキュメントは、プルリクエストにして約2,200行に及ぶ6本のドキュメントです。内訳は、メインが1本、各レイヤーの資料が4本、メンテナンス用が1本となります。

ドキュメントは、概要説明と目次から始まります。LLMは冒頭の情報を重視するため、最初に目次で全体像を示すことが重要です。
次に、Railsのバージョンといったリポジトリの基本情報や、モデル、コントローラーなど各レイヤーの詳細ガイドへのリンクを記載。さらに、具体的なコードサンプル付きのルールも掲載しており、これ一つでも参考になるようになっています。

AIへの失望を防ぐために――ドキュメント作成の背景

AIが良いコードを書けない大きな理由の一つに「社内コーディングルールを知らない」点が挙げられます。ここで言うコーディングルールとは、プロジェクト固有の規約や暗黙知、利用すべき基底クラス、エラーハンドリング方法などです。

AIがルールを知らないと、既存コンポーネントを使わず「車輪の再発明」をしたり、人間による修正コストが増大したりします。
例えば、Userクラスは社内定義のApplicationRecordを継承すべきところをActiveRecord::Baseを継承したり、APIコントローラーはApi::BaseControllerを継承してエラーハンドリングも組み込むべきところをApplicationControllerを継承したりと、多くの手直しが必要になります。結果として「使えない」「手直しが面倒」といった、AIへの失望に繋がります。

この問題は、CursorのRulesやDevinのKnowledgeといった、各ツールに搭載されたナレッジストアを活用することで解消できます。しかし、社内では当初主流だったCursorに加え、GitHub CopilotやDevin、Claudeなど複数のツールが併用されるようになり、ツールは日々増え続けています。

そこで課題となるのが、ツールごとに分散したナレッジの管理です。ツールが乱立すると、ナレッジのバージョン管理や相互参照が困難になります。各ツールのナレッジを個別に育てることも重要ですが、まずはその基盤となる共通のオンボーディングドキュメントが必要だと考えました。

共通ドキュメントにはナレッジの基礎として、ツールからの参照のしやすさ、メンテナンス性、そして情報の一元管理が求められます。リポジトリでコードと共に管理することでこれを実現し、開発者全員が参照できるようにすれば、習熟度に関わらず一定の品質を担保でき、AIへの失望も防げるはずです。

知識抽出とエージェント活用

この記事のつづきを読もう
新規登録/ログインしたらできること
  • すべての記事を制限なく閲覧可能
  • 限定イベントに参加できます
  • GitHub連携でスキルを可視化
ログイン
アカウントをお持ちでない方はこちらから新規登録