ユーザーマニュアル — 窓エディション

TALONが許可したスクリプト領域(窓)の中だけをAIが開発する、標準のエディションです。厳密な開発が必要な場合に推奨する方式で、コードレビューを前提に、本番運用中システムの保守・カスタマイズにも使えます。

1できること

窓エディションのAIは、TALON機能に設けられたスクリプト領域(窓)を対象に、調査・実装・改修・テストを行います。

区分	対象
JavaScriptエンジン	検索前後・確定前後(機能/ブロック)・起動時・帳票出力後・非同期通信・JavaScript呼出・処理呼出
Client-side JavaScript	画面ロード時・各種ボタンのClick時(項目設定のJavaScript呼出ボタンを含む)・項目のFOCUS OUT
CSS	機能個別のCSS
共通ライブラリ	共通JavaScript(サーバー/クライアント)・共通CSSの本体

調査 — 「この機能にどんなスクリプトが設定されているか」「この処理はどこで行われているか」をAIがREST API経由で調べて説明します
実装・改修 — 業務ロジック・入力チェック・画面の使い勝手向上などを、仕様の文章から実装します
テスト — 依頼時に指定すれば、単体テスト(JavaScriptエンジン)とUIテスト(ブラウザ実機)をAI自身が実行し、証跡を残します

機能設定そのものは変更しません — 項目の追加・ボタンの新設などの機能設定はAIの作業対象外です。作業の途中で設定変更が必要になると、AIは作業を止めて「この設定を追加してください」と依頼を返してきます。設定はこれまでどおり人がTALONの設定画面で行います。この分担こそが窓エディションの安全設計です。

2開発の流れ — 入口と出口は人が握る

コード生成とテストはAIに委ねますが、入口(どこに書くかの承認)と出口(最終レビュー)は人がおさえます。

窓エディションの開発フロー。人が仕様を渡し、AIが書き込み先を提案、人が承認(ガードレール1 入口)、AIが窓にコード生成して反映、AIがテストと証跡保存、人が最終レビュー(ガードレール2 出口)

人: 仕様を文章で渡します — 作りたいこと・直したいことを普通の文章でAIに伝えます
AI: 書き込み先を提案します — AIが対象機能の設定を調査し、「どの窓（スクリプト記述領域）に書くか」を提案して確認を求めます
人: 「ここに書いていい」と承認します — 対象のスクリプト記述領域に何も記述が無い場合は、書き込み先を人が承認する必要があります。AIから依頼がありますので、依頼にそって対象のスクリプト記述領域にコメントを1行挿入するなどします
AI: 窓にコードを生成し、反映します — コードはまずローカルファイルとして保存され、その後TALONへ反映されます。差分レビューやGit管理を行うためのファイルとなります
AI: テストを実行し、証跡を保存します — 実施を指定した場合、単体テスト・UIテストを実行し、スクリーンショット等の証跡を保存して完了報告します
人: 最終レビューをします — 差分・テスト証跡を確認し、確からしさを人が確かめてから運用に載せます。レビューには設計情報管理プラットフォーム Commonweal（コモンウィール）をご利用になると効率的に実施できます

3依頼の書き方

依頼は普通の文章で構いません。精度は指示の質に比例します。次の3点を添えると、AIは迷わず正しい場所を触ります。

機能ID・対象箇所 — 「受注入力(機能ID: JYUCYU01)の確定時に」のように、どの機能のどのタイミングかを示します
業務の定義 — 「有効在庫とは、在庫数から引当数を差し引いたもの」のように用語の意味を添えると、出力の精度が目に見えて上がります
関係するテーブル・既存機能 — 更新すべきテーブル名や、動きを確認できる既存機能を添えます

依頼文の例:

受注入力(機能ID: JYUCYU01)の確定時に在庫の引き当てを行ってください。
・受注数を引当数に加算し、有効在庫がマイナスになる場合はエラーとする
・有効在庫が安全在庫数を下回った場合は、警告を表示する
・有効在庫とは、在庫数から引当数を差し引いたもの
・在庫テーブルは T_ZAIKO。在庫照会(機能ID: ZAIKO01)で結果を確認できます

足りない情報があるとき、AIは推測で進めずに質問を返してきます。また、TALONの設定値やAPIの仕様はAIがTALONナレッジMCPサーバで裏を取ってから実装するため、「TALONのどの機能で実現するのが正しいか」から相談することもできます。

4テストと証跡

テスト	内容
単体テスト	JavaScriptエンジンのコードを、専用のテスト実行機能を通じて実行・検証します。テストは回帰スクリプトとして残り、後の変更の安全網になります
UIテスト	AIがブラウザを操作して画面の動作を確認します。スクリーンショット等の証跡が実行日時ごとのフォルダに保存されます

実施はオプトイン — テストは依頼時に「実施する」と伝えた場合のみ行われます(既定では実施しません)。作業の途中で「UIテストして」と頼むこともできます
DBの扱いはAIが確認します — テスト実行前に「DBはスタブにするか、実更新してロールバックするか、そのまま更新するか」をAIが確認してきます

5成果物とフォルダ構成

AIは開発用ルートフォルダの中を次の4つに整理して作業します。src/とtests/をGit管理し、evidence/とwork/は管理対象外とするのが標準です。開発用ルートフォルダはGitなどのバージョン管理下に置くことを強く推奨します。複数人で開発するプロジェクトでは、チームで共有するプライベートリポジトリ(Private GitHubリポジトリ等)を使ってください。

フォルダ	内容
`_local/`	接続情報など、GitHubなどのバージョン管理ソフトにコミットしたくない情報を置きます
`src/`	ソースコード。機能ID・ブロック・ボタンごとに整理され、TALONへ反映した内容の正本になります
`tests/`	単体テストのコード(`src/`の構成をミラー)
`evidence/`	UIテストの証跡(スクリーンショット等)。実行日時ごとにフォルダが分かれます
`work/`	一時ファイル(REST送受信の生データ・認証トークン等)。使い捨ての領域です

6AIが従う安全ルール

AIの動きは、パッケージ同梱の仕様書によって次のように縛られています。

窓（スクリプト記述領域）の外には書かない — AIが使うREST APIはスクリプト領域の更新しかできません。機能設定の変更が必要になったら、AIは停止して人に設定を依頼します
既存レコードの更新のみ — AIは原則としてレコードの新規作成・削除を行いません
実環境が正 — 機能設定の判断は、必ずREST APIで取得した現在の設定を根拠にします。ローカルファイルや記憶からの推測で作業しません
反映前にローカル保存 — TALONへ反映する前に必ずローカルファイルを更新するため、すべての変更が差分として残ります
仕様の裏取り — 設定値・APIの仕様はTALONナレッジMCPサーバで確認してから実装します
資格情報の保護 — 接続先情報は_local/env.jsonで受け渡し、AIはパスワード等をチャット・成果物に書き出しません

これらはAIの動きを縛る仕組みであり、生成されたコードの正しさを保証するものではありません — 成果物のレビューと最終確認は利用者の責任で行います。特に本番運用中のシステムへ適用する場合は、コードレビューとテストを必須としてください(ご利用にあたってを参照)。

7制約と注意事項

ライブラリ参照設定は変更しません — 機能への共通ライブラリの割り当ての変更が必要な場合、AIは人に設定を依頼します
新しい窓にはコメントを1行 — 人が新規に作成したボタン・項目のコード欄が空のままだと、AIがそのレコードを見つけられません。//や/* */のコメントを1行入れておいてください(AIからの設定依頼にもこの案内が含まれます)