参加パスを利用する方
機能要望の投稿と投票
伝わりやすい要望の書き方、投稿の手順、投票と対応状況の読み方を説明します。
投稿前に確認する
対象アプリの要望一覧を読み、同じ課題がすでに提案されていないか確認します。同じ要望があれば投票によって関心を伝えられます。新しく投稿する場合は、一つの要望で一つの課題を扱うと検討しやすくなります。
投稿・投票には、対象アプリの有効な参加パスと残りの利用枠が必要です。ログインや支払いの不具合、個人情報、セキュリティの問題は公開の機能要望へ書かず、無料の問い合わせ窓口を使ってください。
課題・希望する動作・利用場面を書く
機能名だけでは、何を解決すべきか判断できないことがあります。現在の作業、そこで困る理由、改善されたときにできることを順番に書くと、別の方法も含めて検討しやすくなります。
| 項目 | 書く内容の例 |
|---|---|
| タイトル | 検索条件を保存して、次回の一覧表示に再利用したい |
| 困っていること | 毎朝、同じカテゴリと検索語を入力し直している。条件が多いと指定漏れが起きる。 |
| 希望する動作 | 条件に名前を付けて保存し、次回は一覧から選ぶだけで再適用したい。 |
| 利用場面 | 業務開始時に担当アプリを確認する。複数の担当領域を切り替えて使う。 |
投稿・投票の手順
対象アプリの要望画面から操作します。投稿のタイトルは 4〜120 文字で入力し、本文は各入力欄の上限に従ってください。
- 1
新しい要望のフォームを開く
対象アプリを確認し、タイトル、課題、希望する結果、利用場面、カテゴリを入力します。
- 2
内容を見直して送信する
具体的な課題が読み取れるか、秘密の情報がないかを確認します。送信後は詳細画面で受付状況を確認してください。
- 3
既存の要望に投票する
賛同する要望の詳細で投票操作を行います。上限に達している場合は現在の投票先と画面の案内を確認し、必要に応じて投票を取り消して見直します。
対応状況を読む
受付と実装は別の段階です。要望の状態は検討や追加確認によって変わります。対応予定になっても、この表示だけで公開日が確定するわけではありません。
| 表示 | 意味 |
|---|---|
| 受付済み・審査中 | 投稿を受け付け、内容を確認している段階 |
| 受付中・検討中 | 意見を集めたり、実現方法や優先度を検討したりしている段階 |
| 確認待ち・重複 | 追加の確認が必要、または既存の要望と重なる状態 |
| 対応予定・対応中 | 対応方針が決まった、または実装作業が進んでいる段階 |
| リリース済み | 提供された変更を運営が確認した状態 |
| 対応見送り・取り下げ | 今回は対応しない、または要望が取り下げられた状態 |
投稿後の確認と開発への引き渡し
詳細画面で状態や案内を確認します。一部の要望は運営の確認後に AgenticSupportSystem へ引き渡され、承認された開発課題の GitHub Issue リンクが記録されます。すべての要望がこの連携に進むとは限りません。
外部の Issue が閉じられても、ポータルの状態が自動でリリース済みに変わる仕組みではありません。利用者向けの状態は、実際の提供状況を運営が確認して更新します。