内製アプリとClaudeスキルのセキュリティチェック、 Backlogの課題で回しています。

JBUG東京#30 Backlog活用事例とAIで考える、これからのチームのかたちhttps://jbug.connpass.com/event/409444/
での登壇資料です

Transcript

1. JBUG東京#30 ユーザー事例 内製アプリとClaudeスキルのセキュリティチェック、 Backlogの課題で回しています。 AIガバナンスを現場で続ける話 Ayaka Suzuki ／ 株式会社ネクスタ CTO室 コーポレートIT 2026-11-06 ヌーラボ東京事務所
2. 自己紹介 QAとIT統制と技術広報を、ひとりで回しています Ayaka Suzuki 株式会社ネクスタ CTO室 コーポレートIT 組込みエンジニア 13年。2024年10月からQAエンジニアに転向 いまはQA、IT統制（ISMS）、技術広報、社内ITを兼務 Backlogは課題・Wiki・Gitを毎日使う側。管理者でもあります 作っているもの:中小製造業向けの生産管理SaaS「スマートF」。受発注・在庫・生産実績・原価を扱います。 目標は、日本を変えるプロダクトを作ること。 JBUG東京#30 2 / 15
3. 困りごと 基準と判定が、Backlogの外に散っていた 1 基準 2 判定 3 記録 ドキュメントに書いてある。 チャットで聞かれて、 担当者の記憶。 ただし置き場所が複数あり、 どれが最新か分からない チャットで答える。 流れて消える 同じ指摘を何度もする。 引き継げない 内製アプリとClaudeスキルは、これからも増える。続けるには、一か所に寄せるしかない。 JBUG東京#30 3 / 15
4. 結論 Backlogを「AIが読み書きする場所」にした Claude Code（スキル）＋ Backlog MCP Wiki 課題 Git ＝ 基準の正本 ＝ 判断の履歴 ＝ スキルの配布 AIが読む。 判定基準、チェックリスト、 AIが起票し、人が判定する。 結果は属性と状態に残る スキルを置き、PRで直す。 Wikiと同じ場所にある 手順書はここにしかない JBUG東京#30 4 / 15
5. 前提 Backlog MCPで、何を読み書きしているか Claude Code（スキル） Backlog MCP（ヌーラボ公式） Backlog（Wiki・課題・Git） スキルがMCP経由で行うこと 読む Wiki（判定基準・チェックリスト・手順書） 読む 課題種別、優先度、カスタム属性の一覧。IDではなく名前で選ぶため 書く 課題の起票（種別・優先度・属性を付けて） 書く Wikiの更新（基準や手順を直すとき） MCPが使えない環境や、エラーのときは、コピペ用の本文を出すだけに落とす。止めない。 JBUG東京#30 5 / 15
6. Wiki ① 基準はスキルに埋め込まず、Wikiを正本にする 判定基準 チェックリスト ホワイトリスト 申請フロー 廃止フロー 既定値 Wiki 6ページ（セキュリティチェックの基準と手順） スキル（SKILL.md）の実物。「判定前に、このWikiを読め」としか書いていない スキルは実行時にWikiを取りに行く。基準の本文はスキルに持たない 基準を直すのはWikiだけ。スキルは配り直さない JBUG東京#30 6 / 15
7. Wiki ② AIが読みやすい書き方に寄せた 書き方 ねらい 冒頭に、AIへの頼み方を一文で書く 人は「確認して」と頼むだけ。前置きや経緯を省き、判定に要る情報だけ読ませる 判定はYES/NOの質問にして、コードブロックに入れる 解釈の揺れをなくす。AIも人も同じ質問に答える 表の列は「意味」「次に動かす人」で固定する 列を増やさない。誰が次に動くかが毎回わかる 既定値には理由を書く 理由があれば、例外のときに判断できる 「整備中の項目は指摘対象外」と明示する 未整備の項目を欠陥として指摘させない Wikiの実物:判定フロー（YES/NOの質問） Wikiの実物:整備中の項目は指摘対象外 JBUG東京#30 7 / 15
8. Wiki ③ 手順書は、AIに実行させる前提で書く コマンド列をそのまま載せる 非エンジニアには「AIへの頼み方」の例文を置く claude plugin marketplace add <リポジトリURL> claude plugin install <プラグイン名> 「このWikiの手順どおりに、 claude plugin list セキュリティチェックのスキルを入れて」 手順書の読み手もAI。人は「頼む」だけで、コマンドはAIが実行する 初回のGit認証だけは人がやる。そこは手順書に「ここは人」と書く 改訂日と出典を書く。スキルと手順書がずれたとき、どちらが古いか分かる JBUG東京#30 8 / 15
9. Git スキルはBacklog Gitで配る Backlog Git の実物:スキルの marketplace（プラグインの置き場） 1 必須スキル 管理設定で全員に自動配布 セキュリティチェックなど、やらないと困るもの 2 任意スキル 各自が手順書どおりに追加 部署や役割で要るもの。入れるかは本人が決める 直すときは PR Backlog Git の実物:コミット履歴。スキルを直した記録が、Wikiや課題と同じ場所に残る 強みは、Wikiと課題と同じ場所にあること。手順書からリポジトリへ、課題からPRへ、同じ画面で行き来できる。 JBUG東京#30 9 / 15
10. 課題 ① AIが起票する課題の設計 Claude Code の実物 ①:起票前の確認は、この一度だけ 1 名前で選ぶ 種別・優先度・属性のIDは決め打ちしない。実行時に一覧を 読んで「セキュリティチェック」を名前で探す Claude Code の実物 ②:起票の結果。URLではなく課題キーを表示する 2 確認は一度だけ 「この内容で起票してよいか」だけ聞く。属性の値は聞かない 種別「セキュリティチェック」、 優先度、カスタム属性「レベル」は AIが実行時に取得して設定する。 本文は、体制・デプロイ設定・ 権限・データ保存・外部送信先。 3 課題キーを表示 MCPの結果にURLはない。URLを組み立てず、課題キーを 出して人が開く JBUG東京#30 10 / 15
11. 課題 ② 人の判定は、課題の属性と状態に残す 未対応 処理中 申請者対応待ち 完了 審査者が戻す 状態を動かすのは審査者。申請者は状態を戻さず、コメントで回答する。クローズ＝承認。 カスタム属性 選択肢 判定 承認 ／ 条件付き承認 ／ 要是正 ／ 差し戻し レベル Lv.1 ／ Lv.2 ／ Lv.3（AIが起票時に入れ、審査者が確定する） 指摘区分 外部送信 ／ 権限過剰 ／ 公開範囲 ／ 認証情報の管理 ／ 文書不備 ／ 体制不 備 ／ 保存期間と削除ルール ／ その他 Backlog の実物:審査後に属性が埋まった課題 指摘には期限を付ける。回答が来たら期限を引き直す。属性で絞れば、どの区分の指摘が多いかが課題一覧で見える。 JBUG東京#30 11 / 15
12. 課題 ③ 課題のコメントを、WikiとスキルにPRで戻す 課題のコメント PR Wiki と スキル 審査で繰り返し聞いた観点が コメントに溜まる 観点をチェックリストと 起票本文の必須欄に足す 改訂日と、どの審査で決めたか （出典）を書く 次の申請から、AIが先に聞く 判断の材料は、課題のコメントに全部ある。分類も集計も、Backlogの中で済む Wikiとスキルに戻すと、同じ指摘が次の申請で出なくなる。審査は楽になり、申請者は待たされなくなる JBUG東京#30 12 / 15
13. うまくいかなかったこと 崩れたところ 崩れたところ 直したこと Wikiとスキルがずれた。 手順書が旧記述のまま残り、AIが古い手順を実行した Wikiに改訂日と出典を書き、スキルの改訂時にWikiも同じPRで直す 初回のGit認証だけは、AIに任せられなかった 人がやると割り切り、手順書に「ここは人」と書いた AIが書いた申請文を、人がBacklogに貼っていた。 自動化したつもりの名残が残っていた Backlog MCPで起票まで自動化。人は「起票してよいか」に答えるだけ どれも「AIが読む場所」と「AIが書く場所」を決めきれていなかったのが原因。場所を決めると、名残は見つかる。 JBUG東京#30 13 / 15
14. まとめ 持ち帰り 3つ 1 ツールを増やさない いまあるBacklogを使う。基準も判定も記録も、ここに寄せる 2 基準と手順は、AIが読む場所に置き、AIが読みやすく書く Wikiを正本にして、読み手はAIと決める。質問はYES/NO、表の列は固定、既定値には理由 3 人の判断は課題の属性に残し、WikiとスキルにPRで戻す 判定・レベル・指摘区分を属性に。繰り返す指摘はチェックリストと起票本文へ JBUG東京#30 14 / 15
15. 最後に 私たちは、日本を変えるプロダクトを作っています セキュリティチェックの続きと、Backlogの使い方の細かい話は、テックブログに書いていきます。 質問や感想は、Xか、この後の感想シェアリングで。 Nexta Tech Blog（Zenn） @Egachaaan_dev テックブログ X ご清聴ありがとうございました