メインコンテンツへスキップ

TALON AI Developer - ユーザーマニュアル（まるごとエディション）

  • 更新

ユーザーマニュアル — まるごとエディション

機能設定からスクリプトまで、TALONの業務アプリをAIがまるごと開発するエディションです。PoC・プロトタイプ開発など、たたき台を素早く形にしたい場面に向きます。本番と分離された開発環境で使います。

本番と分離された開発環境で使います(必須) — まるごとエディションはAIがリポジトリ(機能設定)へ直接書き込むため、一定のリスクを前提とします。AIが正しい機能を構築することを保証するものではなく、生成された機能・設定の確認は利用者の責任で行ってください(ご利用にあたってを参照)。AIは本番環境へ直接書き込みません。本番への反映は、人によるレビューとTALON標準のリポジトリ移送で行います。本番品質の厳密な開発・保守には窓エディションが適しています。

1まるごとエディションとは

通常は人がTALONの機能設定画面で行う設定作業を、AIがリポジトリテーブルへの直接書込みで代行するエディションです。要件を文章で渡すだけで、画面・検索・確定処理・ボタン・スクリプトを含む業務アプリのたたき台を、AIが短時間で構築します。

ただしAIが書くのは機能設定の全体であり、窓エディションのような「書ける範囲の構造的な限定」はありません。その釣り合いとして、まるごとエディションは本番と分離された開発環境での使用と、機械検証・三層検証・人の承認という運用ゲートを必須にしています。

2できること

区分 内容
できること TALON機能の新規構築(画面・検索・確定・ボタン・LOOKUP・入力チェック等)/構築済み機能の設定変更/業務テーブルのDDL(人の承認制)/スクリプトの実装/単体テスト・UIテスト

3はじめる前に

  • 本番と分離された開発環境で使います(必須) — 壊れても困らないTALON+DBを用意します。環境の準備はセットアップガイドの4章を参照してください
  • 本番と分離された開発環境であることを宣言します — 接続先情報ファイル_local/env.jsonのenvKind欄にverificationと記入します。この宣言がない限り、AIは作業を開始しません
  • TALONナレッジMCPサーバへの接続が必須です — 実証済み手順書・マニュアル・リポジトリ構造の参照、実例の参照、機械検証がすべてMCPサーバ経由のため、未接続では構築を開始しません

4開発の流れ — 構築と三層検証

まるごとエディションの開発フロー。人が要件を渡し、AIが設定を生成・保存、機械検証を通し、必要ならDDLを人が承認、AIがリポジトリへINSERTして反映、三層検証を実行し、人が動作確認する
  1. 人: 要件を文章で渡します — 作りたい機能・対象の業務テーブル・画面のイメージを伝えます
  2. AI: 設定を生成し、保存します — 生成した設定・反映用SQLはローカルファイルとして保存され、あとから差分で確認できます
  3. AI: 機械検証を通します — 生成した設定を検証ツール(validate_settings)にかけ、通過するまで反映しません
  4. 人: 業務テーブルのDDLを承認します(必要時) — 新しいテーブルの作成が必要な場合、AIは対象とSQLを提示して承認を求めます。承認なしにDDLは実行されません
  5. AI: リポジトリへ反映します — 既存への影響を事前確認・バックアップした上でINSERTし、TALONへ反映します
  6. AI: 三層検証を実行します — 下表の3つの検証をすべて通過してはじめて「構築完了」です(省略不可)
  7. 人: 動作を確認します — 実際に画面を操作して確認し、修正点をフィードバックします。修正のたびに機械検証・三層検証が繰り返されます

▦三層検証とは

AIがリポジトリへ直接書いた設定は、TALONの設定画面が持つ入力チェックを通っていません。そこで構築のたびに、次の3層の検証を必ず行います。

検証 内容
第1層: REST検証 機能のロードと検索をREST APIで実行し、エラーがないことを確認します
第2層: ブラウザ実機検証 AIがブラウザで実際に画面を開き、検索・入力・確定を操作します。RESTだけでは見つからない画面表示・ダイアログの不備を検出します
第3層: 設定画面ラウンドトリップ AIが書いた設定をTALON自身の設定画面で開いて保存し直し、エラーが出ないこと・データが変わらないことを確認します。動くけれどもTALONの正式な設定として正しくない状態を、ここで検出します

5ガードレール

まるごとエディションのAIは、仕様書とMCPサーバの二重の宣言で次のルールに縛られています。

  • 本番と分離された開発環境でのみ動作 — env.jsonに本番と分離された開発環境であることの宣言がなければ作業を開始しません。接続先の要約を提示し、人の確認を得てから着手します
  • 本番環境へは書き込みません — 例外はありません。本番への反映は人の承認と人によるリポジトリ移送で行います
  • 機械検証を通過しない設定は反映しない — validate_settingsが必須ゲートです
  • 破壊的操作は承認制 — 業務テーブルのDDL、DROP・TRUNCATE・全件DELETEなどは、対象とSQLを提示して人の明示承認を得るまで実行しません
  • 変更前バックアップ — 既存行を変更する前に、変更前の状態を保存します
  • 成果物はローカルに残る — 生成した設定・SQL・スクリプトはすべてローカルファイルとして残り、何をどう変えたかを後から追えます。開発用ルートフォルダをGitなどのバージョン管理下に置くことを強く推奨します(複数人での開発ではチーム共有のプライベートリポジトリを使います)

※ただし、これらの操作もAIが100%守るとは限りません。一定のリスクがある前提の下でご利用ください。

6依頼の書き方

窓エディションと同じく、業務の定義・関係するテーブル・参考になる既存機能を添えると精度が上がります。依頼文の例:

受注入力と在庫照会の2画面からなるPoCを作ってください。
・受注入力: 得意先・品目・受注数を入力し、確定時に在庫を引き当てる。
  受注テーブル T_JYUCYU は新規作成してください(構成は任せます)
・在庫照会: 品目ごとの在庫数・引当数・有効在庫を一覧表示する。
  在庫テーブル T_ZAIKO は既存です
・有効在庫とは、在庫数から引当数を差し引いたもの
・有効在庫がマイナスになる確定はエラーにしてください
既存の品目マスタ保守(機能ID: MST_HINMOKU)の画面の作りを参考にしてください。
  • 画面イメージは既存機能で伝えられます — 「この機能と同じ作りで」と実在の機能IDを添えると、AIがその実設定を出発点にして作りを踏襲します。TALONのナレッジに照らして修正が必要な設定と、より良い作りの代替案がある場合は、生成前にまとめて提示されるので選んでください（「任せる」と答えると、参考機能の作りを既定にして進めます）
  • まず小さく作るのがコツです — 一覧保守1本から始めて、動きを確認しながら画面や処理を足していくと、フィードバックのサイクルが短くなります
  • 設計情報管理プラットフォーム Commonweal（コモンウィール）を使う — 設計情報がMarkdownファイルで出力されるので、それらの情報を読みこませることで精度向上が見込めます

7PoCを本番化するには

まるごとエディションで作ったPoCをそのまま本番に載せることはできません。本番化は次の道筋で行います。

  1. 人がレビューします — TALONの設定画面で設定内容を確認し、業務として正しいかを検証します(三層検証を通過した設定は、設定画面でそのまま開けます)。さらに、Commonwealで設計書出力してレビューをすると効率が良くなります。Commonwealには設計情報の比較ができますので、機能改善前と改善後の設計書情報を比較させることができます
  2. 人が移送します — TALON標準のリポジトリ移送機能で、開発環境から本番環境へ人が移送します。AIはこの工程を自動化しません
  3. 本番に載った後の改修は窓エディションが適しています — 本番に載った機能のスクリプト改修・カスタマイズは、厳密な開発が必要な場面として窓エディションで行うことを推奨します。構築はまるごと、本番後の改修は窓、という使い分けが基本です