利用者・アプリ担当者

AgenticSupportSystem との連携

機能要望を開発課題へつなぐ、人による確認、引き渡し、Issue 記録、状態更新の流れを説明します。

このページの内容

連携の目的

Sephiroth System に寄せられた機能要望を、開発側が扱える課題に整理し、AgenticSupportSystem へつなぎます。投稿内容をそのまま自動実装する仕組みではなく、運営が内容を読み、必要な情報を整理して引き渡す流れです。

両システムは独立して運用されます。ポータルへのログインが AgenticSupportSystem のログインを兼ねるわけではなく、投稿によって外部の開発作業が自動で開始されることもありません。

検討中または対応予定になった要望のうち、開発への引き渡しが適切なものを運営が扱います。採用や引き渡しの対象は、要望の内容と開発判断によって決まります。

1
要望を確認する
課題、期待する結果、利用場面を読み、重複や不足情報を確認します。必要なら内容を整理してから次の段階へ進みます。
2
引き渡す要約を人が確認する
開発側に必要な情報をまとめ、公開範囲や個人情報、秘密の情報が含まれていないかを確認します。自動的な加工だけに任せず、送る前に確認します。
3
AgenticSupportSystem 側で扱う
担当者が、外部システムの受け付けと承認の手順に従って課題を引き渡します。Sephiroth System が直接 GitHub Issue を自動作成するわけではありません。
4
承認された Issue のリンクを記録する
GitHub Issue が作成された場合、その URL をポータル側の要望に記録します。利用者は表示されたリンクから関連する開発課題を確認できます。

引き渡す情報は、実装方法を決めつける指示よりも、解決したい課題と達成条件を中心にします。個人を特定しなくても再現できるように、固有のデータは必要に応じて置き換えます。

引き渡し要約の例

課題: 毎回同じ検索条件を入力している。
期待する結果: 保存した条件を選択して検索を再実行できる。
利用場面: 担当領域を切り替えながら、毎朝アプリ一覧を確認する。
確認したいこと: 条件の保存範囲、編集と削除の方法。
関連する要望: ポータルの公開要望 URL。

GitHub Issue は開発課題を追跡するための記録です。リンクがあることだけで、実装が確約された、公開日が決まった、作業が完了したとは判断できません。

Issue の終了と、利用者に機能が提供される時点は異なる場合があります。現在の連携では、外部の Issue が閉じられても、ポータルの要望が自動でリリース済みに変わることはありません。運営が提供状況を確認して更新します。

引き渡し時の確認は、公開投稿に秘密を書いてよい理由にはなりません。要望にはパスワード、API キー、顧客データ、非公開の URL などを含めないでください。

公開できない事情を伴う課題は、問い合わせ窓口で相談してください。要望の提出や投票によって、外部システムでの承認や特定の対応期限が保証されるわけではありません。