AIを活用すれば、テストケースやテストスクリプトの作成、テスト結果の分析など、これまで人が時間をかけていた業務を効率化できます。 一方で、「AIが作成したテストケースをそのまま採用してよいのか」「重要な確認項目が抜けていないか」と不安を感じる場面も少なくありません。 生成AIは、自然で説得力のある内容を出力できても、実際の仕様とは異なる情報を生成することがあります。 さらに、ソースコードやログ、顧客情報などを入力することで、情報管理上のリスクが生じる可能性もあります。 そのため、AIによるテスト管理で大切なのは、すべてを自動化することではなく、 AIに任せる範囲と人が判断する範囲を明確にすること です。 AIを便利な補助役として活用しながら、人が品質をコントロールできる仕組みを作ることで、効率化と品質保証を両立しやすくなります。 そこで今回は、AIでテスト管理をする際に押さえておきたい注意点と、安全に活用するための運用方法を実務の流れに沿ってまとめました！ AI導入を検討している場合はもちろん、すでにテスト業務で生成AIを使い始めている場合にも確認しておきたい内容です。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テスト管理ツール11製品の完全比較はこちら▼ 【2026年最新】テスト管理ツール11製品の徹底比較！【脱Excel】 AIでテスト管理をするなら、まず知っておきたい5つの注意点！ AIを活用したテスト管理では、テストケースの作成や結果分析など幅広い業務を効率化できます。 実際に、テストケースやテストスクリプトの作成、テスト実行、テスト結果の分析などはAI活用が進んでいる領域です。 ただし、効率化できるからといって、そのままAIへ任せきるのは避ける必要があります。 生成AIには誤った情報を生成する可能性があり、さらに利用するデータやAIエージェントへ与える権限によっては、品質問題だけでなくセキュリティ問題につながることもあります。 まずは、AIをテスト管理へ取り入れる前に押さえておきたい5つの注意点を確認していきましょう。 AIの回答は「正解」ではない！テストケースの誤りや抜け漏れを前提に確認する 生成AIが作成したテストケースは、完成品ではなく 人が確認するためのたたき台 として扱うことが重要です。 生成AIでは、事実とは異なる内容を自然な文章で出力する「ハルシネーション」が発生する場合があります。 正確な情報を与えた場合でも誤った出力が生じる可能性があるため、「AIが自信を持って回答しているから正しい」と判断するのは危険です。 テスト管理でも、存在しない仕様を前提としたケース、期待結果の間違い、条件の取り違え、似た内容の重複などが混ざる可能性があります。 また、100件のテストケースが生成されたとしても、重要なリスクを確認できていなければ、網羅性が高いとはいえません。 特に確認したいのは、 仕様との一致、テスト観点の漏れ、期待結果の妥当性、重複、優先順位 です。 AIが作った項目数ではなく、「重大な不具合につながる条件を確認できているか」という視点で評価することが大切です。 最終的な採用判断は、仕様や要求、業務上のリスクを理解している人が行う運用にしましょう。 AIだけでは拾いにくい！業務知識・異常系・非機能要件を見落とさない 生成AIは、入力された仕様書や要求事項から一般的なテストケースを展開することを得意とします。 しかし、 仕様書に書かれていない背景や現場特有の事情まで自動的に理解できるとは限りません 。 たとえば、「この操作は実際のユーザーが頻繁に間違える」「以前この組み合わせで重大障害が起きた」といった知識は、資料として与えなければ反映されない可能性があります。 AIは過去のパターンを利用した分析を得意とする一方、まれに発生するものの影響が大きい不具合や、新しい利用パターンなどを適切に優先できないこともあります。 正常系だけでなく、境界値、異常入力、権限違い、通信障害、同時操作、タイムアウトなどが含まれているか確認しましょう。 性能、セキュリティ、アクセシビリティ、ユーザビリティといった 非機能要件 も、人が意識して補う必要があります。 「AIにすべてのテスト観点を考えてもらう」のではなく、「人が重要な観点を定義し、AIに展開してもらう」と考えると、AIを活用しながら品質を保ちやすくなります。 仕様書や不具合情報をそのまま入力しない！機密情報の漏えいを防ぐ AIをテスト業務で利用する際は、 何を入力してよいかを事前に決めておくこと が欠かせません。 テスト担当者が普段扱う仕様書、ソースコード、ログ、障害票、問い合わせ履歴、テストデータには、社外へ出してはいけない情報が含まれていることがあります。 特にソースコード、ユーザー情報、内部文書などを外部のAIサービスへ入力する場合は、データ漏えいや知的財産に関するリスクを考慮する必要があります。 利用するAIサービスについて、入力内容が保存されるのか、モデル改善などに利用されるのか、管理者側で利用状況を確認できるのかを事前に調べておきましょう。 必要に応じて、学習利用を制限できる企業向け環境や、組織として管理できるサービスを選択する方法もあります。 本番環境の情報を使用する必要がない場合は、個人情報を匿名化したり、値をマスキングしたり、ダミーデータへ置き換えたりする方法も有効です。 担当者ごとの判断に任せず、 入力可能な情報と入力禁止の情報を明文化すること が、安全なAI利用の基本となります。 勝手なAI利用を放置しない！ツール・権限・利用範囲を決める AI活用では、公式に許可されていないAIサービスを従業員が業務で使用する シャドーAI にも注意が必要です。 業務を効率化しようという善意から始まった利用でも、会社側が把握していないサービスへ仕様書やソースコードを入力すれば、情報管理上の問題が発生する可能性があります。 そのため、「AIは禁止」とするだけでなく、業務で利用できるAIサービスやアカウント、用途を明確にすることが重要です。 さらに注意したいのが、AIエージェントをテスト管理ツールやリポジトリへ接続するケースです。 文章を生成するだけのAIとは異なり、AIエージェントはファイル変更や外部システムへのアクセスなどの操作まで行う場合があります。 必要以上の権限を与えると、誤った判断によってテストケースや重要データが変更されるリスクが広がります。 AIへ与える権限は 業務に必要な最小限の範囲 に絞り、重要な変更や削除については人の承認を必須にすると安心です。 「なぜこのテストをしたのか」を残す！説明できないAI運用を避ける AIを使ってテストケースを生成する場合、完成したテストケースだけを残す運用には注意が必要です。 後から障害が発生した際、「なぜこのケースを採用したのか」「なぜこのテストを省いたのか」を確認できなければ、原因分析や改善が難しくなります。 AIによる判断が増えるほど、 結果だけではなく判断までの過程を追える状態 を作ることが重要になります。 たとえば、参照した仕様、AIへ与えた指示、生成されたテストケース、人が修正した箇所、確認者、承認者などを必要な範囲で記録します。 AIシステムでは、判断の理由が十分に見えない場合があり、生成された推奨内容をそのまま信頼すると危険な前提をテスト工程へ持ち込む可能性があります。 AIエージェントを利用する場合も、操作ログを残し、想定外の動作が発生した際に追跡できる仕組みが重要です。 AIを利用しても品質保証の責任そのものがAIへ移るわけではないため、「誰が確認し、誰が判断したか」を説明できる運用にしましょう。 AIに任せる仕事と人が判断する仕事を切り分けよう！ AIでテスト管理を成功させるためには、「AIに何ができるか」だけでなく、 どこまでAIへ任せるか を考える必要があります。 生成AIは、大量の情報整理やテストケース候補の作成など、人が時間を取られやすい作業を短縮する力があります。 一方で、ソフトウェア品質には動作の正しさだけでなく、使いやすさ、セキュリティ、性能、ビジネス要求への適合など複数の視点が含まれます。 すべてをAIに任せようとするのではなく、AIが得意な処理と、人の経験や判断が必要な処理を組み合わせることが重要です。 ここからは、AIと人の役割をどのように分けるとよいかを整理します。 AIが得意なのは「たたき台づくり」と「大量処理」 AIが力を発揮しやすいのは、 一定の情報をもとに候補を大量に作る作業や、情報を整理する作業 です。 たとえば、仕様書からテスト観点の候補を洗い出したり、テストケースやテストスクリプトの初稿を作成したりする用途があります。 既存テストケースの分類、表現の統一、似たケースの抽出、テスト結果や障害情報の要約にも活用できます。 AIを使ったテストでは、テスト生成や結果分析、変更に応じたテストの調整など、従来より幅広い工程を効率化できるようになっています。 こうした作業では、人がゼロから文章や一覧を作成する時間を短縮できるため、AI活用による効果を得やすくなります。 ただし、AIが作った内容をそのまま品質保証の根拠にするのではなく、あくまで 判断材料を高速に作る補助役 として利用するのがポイントです。 人はAIが作った材料を確認し、業務知識やリスクを踏まえて必要なものを選び、修正する役割を担います。 人が手放してはいけないのは「品質基準」と「最終判断」 AI活用が進んでも、 何をもって品質が十分と判断するのか は人が決める必要があります。 テスト対象には、単純な動作確認だけでは判断できない要求が数多くあります。 たとえば、ユーザーが迷わず操作できるか、重大事故につながる使い方がないか、法令や社内基準を満たしているかといった判断には、業務や利用者への理解が必要です。 人は「利用者が想定外の操作をしたらどうなるか」「画面の流れが分かりにくくないか」といった、文書化された仕様だけでは捉えにくい問いを立てることができます。 テスト方針、優先順位、テスト終了基準、重大不具合の判定、リリース可否など、説明責任を伴う判断は人が担うのが基本です。 重要なワークフローでは、 人がAIの出力を確認する仕組み を組み込むことが、安全性を高めるポイントになります。 AIが処理を高速化し、人が品質を判断する役割分担を作ることで、効率化と信頼性を両立しやすくなります。 AIに任せる範囲は「失敗したときの影響」で決める AIへ任せる範囲を決める際は、作業が簡単か難しいかだけではなく、 AIが間違えた場合の影響度 で考える方法が実践的です。 たとえば、テストケース候補の文章を整える作業であれば、人が後から修正しやすいためAIへ任せやすいでしょう。 一方、重大な不具合の判定やテスト省略の判断、リリース可否などを誤ると、ユーザーや事業への影響が大きくなる可能性があります。 影響が大きい処理ほど、人によるレビューや承認を厚くする必要があります。 特にAIエージェントがテスト管理ツールへ直接変更を加える場合は、重要な操作に人の承認を挟む仕組みが有効です。 最初から完全自動化を目指すのではなく、 AI生成→人によるレビュー→承認 という流れから始めると、問題点を把握しながら段階的に利用範囲を広げられます。 評価するときも自動化率だけを見るのではなく、作業時間、レビュー工数、修正量、欠陥検出、手戻りなどを含めて判断しましょう。 安全にAIを使うなら、チームで守る運用ルールを決めよう！ AI活用の安全性を担当者個人の知識や注意力だけに頼ると、使い方にばらつきが生まれます。 同じチームでも、ある担当者は機密情報を入力せず、別の担当者は仕様書をそのまま入力しているという状態になれば、組織としてリスクを管理できません。 AIの業務利用が広がるなかでは、安全な利用に向けて組織内の規程や体制を整えることが重要なテーマとなっています。 また、生成AIを利用するシステムでは、利用目的から必要な品質を定め、各構成要素へ管理策を設定する考え方も重要です。 AI利用を禁止するのではなく、安全に使える共通ルールを作ることで、現場がAIのメリットを活かしやすい環境を整えましょう。 最初に決めたい！AI利用ルールのチェック項目 AI利用ルールを作る際は、最初から複雑な規程を作ろうとせず、 誰が・何を・どこまでAIに任せられるのか を明確にするところから始めましょう。 まず、業務で利用を許可するAIサービスやアカウントを決め、未承認サービスを個人判断で使わないようにします。 次に、入力できるデータと入力禁止データを分類します。 個人情報、顧客情報、非公開のソースコード、認証情報、未公開製品の仕様などは、情報の重要度や利用サービスの契約条件を踏まえて扱いを決める必要があります。 さらに、AIが生成したテストケースを誰が確認するのか、どの作業で承認が必要なのかを決めます。 プロンプト、生成結果、修正内容、実行ログ、承認者など、後から確認する必要がある情報の保存範囲も整理しておきましょう。 会社が把握していないAIの利用を防ぐためには、 利用可能なAIを分かりやすく提示し、現場が正式な環境を使えるようにすること も大切です。 AI生成テストはこの順番でレビューする！ AI生成テストを効率よくレビューするためには、担当者ごとに確認方法を変えるのではなく、 チェックする順番を決めておくこと が有効です。 最初に確認したいのは、要求や仕様と一致しているかです。 存在しない機能や誤った前提が含まれていれば、それ以降のテスト内容も正しく評価できません。 次に、正常系、異常系、境界値など必要なテスト観点が漏れていないかを確認します。 その後、それぞれの期待結果が正しいか、似た内容が重複していないか、重要度の低いテストが大量に生成されていないかを見ていきます。 最後に、過去障害、問い合わせ、業務上の例外、性能やセキュリティなど、 AIだけでは判断しにくい現場固有の観点 を補います。 テスト観点を体系化して提示することは、生成AIを利用するシステムのテストケースを多様化するうえでも有効性が検討されています。 この確認手順をチェックリスト化すれば、AI活用者が増えてもレビュー品質をそろえやすくなります。 小さく試して効果を測る！AI導入を成功させる進め方 AI導入では、最初からすべてのテスト工程を置き換えようとせず、 限定した業務から試すこと が重要です。 たとえば、既存仕様からのテストケース候補作成や、テスト結果の要約など、失敗しても人が修正しやすい作業から始めます。 試行前には、テストケース作成時間、レビュー時間、修正数、欠陥検出数など、比較したい指標を決めておきましょう。 AI導入後に作成時間が半分になっても、レビューや修正に以前より時間がかかっていれば、チーム全体では効率化できていない可能性があります。 AIモデルや利用環境によって出力特性が変わる可能性もあるため、一度評価して終わりではなく、継続して品質を確認することが必要です。 生成AIを利用するシステムでも、想定用途から品質要件を定め、各構成要素へ必要な管理策を適用する体系的な品質管理が重視されています。 効率とリスクの両方を数値や事例で確認し、問題なく運用できる範囲から徐々に広げること が、無理のない導入につながります。 AIを「品質保証の代役」ではなく「品質を高める補助役」にしよう！ AIをテスト管理へ導入する目的は、人の判断をすべてなくすことではありません。 AIには、大量の情報を短時間で処理し、テストケースやスクリプトの候補を生成したり、テスト結果から傾向を見つけたりできる強みがあります。 一方、人には、利用者の行動や業務背景を理解し、重大なリスクを見極める強みがあります。 AI支援型の品質保証では、 効率を高める場所と、人の専門性を残す場所を慎重に選ぶこと が重要です。 AIと人を競わせるのではなく、それぞれが得意な部分を組み合わせることで、テスト管理全体の品質を高めていきましょう。 AI導入の目的を「テスト件数を増やすこと」にしない 生成AIを使えば、短時間で大量のテストケースを作ることができます。 しかし、生成された件数が多いほど品質が高いとは限りません。 重要性の低いケースや似たケースが大量に生成されれば、確認する側の負担が増え、かえって重大なテスト項目を見落としやすくなる可能性もあります。 AIテスト支援では、過去の傾向から重要度を推定したりテストケースを生成したりできますが、まれに起こる重大な不具合や新しい利用状況を正しく評価できない場合があります。 そのため、AI導入の評価指標を「何件作ったか」や「何％自動化したか」だけにしないことが大切です。 重要な欠陥を発見できたか、レビュー負荷が下がったか、手戻りが減ったか、品質を保ったまま時間を短縮できたか まで確認しましょう。 AIによって浮いた時間を、仕様レビューや探索的テスト、リスク分析など、人の判断が価値を生みやすい作業へ振り向けることが、本来の効率化につながります。 「AIを使っているから不安」から「AIを使っていても説明できる」状態へ 安全なAI活用で目指したいのは、「AIだから信用する」状態でも、「AIは危険だから使わない」状態でもありません。 AIがどこで使われ、何を生成し、誰が確認し、誰が最終判断したのかを説明できる状態 を作ることが重要です。 AIに任せる業務、人がレビューする業務、承認が必要な業務を明確にすれば、担当者ごとの判断のばらつきを抑えられます。 さらに、プロンプトや生成結果、修正履歴、承認記録を必要な範囲で残しておけば、問題が発生したときにも原因を追いやすくなります。 AIが理由を十分に説明できないままテストの省略やリスク評価を提案する場合もあるため、重要な判断では根拠を確認できる仕組みが欠かせません。 利用ルールやレビュー基準をチェックリストとして共有すれば、特定の担当者だけがAIを使いこなせる状態から、チーム全体で安全に活用できる状態へ移行できます。 AI活用そのものを目的にせず、 品質を説明できるテスト管理を維持しながら効率を高めること を目指しましょう。 まとめ｜AIに任せきらず、人が品質をコントロールできるテスト管理へ！ AIをテスト管理へ取り入れることで、テストケースやスクリプトの作成、結果分析などの作業を効率化できます。 一方で、AIには誤った内容の生成やテスト観点の抜け漏れがあり、入力するデータによっては情報漏えいのリスクも考えられます。 AIエージェントを外部ツールと連携させる場合は、必要以上の権限を与えないことや、重要操作に人の承認を入れることも大切です。 AIが作った結果は完成品ではなく、 人が確認して品質を高めるためのたたき台 と考えると、安全に活用しやすくなります。 AIには大量処理や候補作成を任せ、人は品質基準、リスク判断、最終承認といった役割を担当しましょう。 まずは「利用できるAI」「入力できる情報」「レビュー方法」「承認者」「残す記録」の5点を整理すると、運用ルールを作り始めやすくなります。 最初から完全自動化を目指す必要はありません。 小さな範囲からAIを試し、品質と工数の変化を確認しながら、安全に任せられる範囲を少しずつ広げていくことが重要です。 AIを品質保証の代わりにするのではなく、人がより重要な品質判断へ集中するための補助役として活用していきましょう。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

はじめに CyberAgent group Infrastructure Unit（CIU）の川原で ...

はじめに こんにちは、Insight Edge の日下です。 ここ最近のコーディングAIエージェントの進化は目覚ましく、以下のような光景が当たり前になってきました。 プロダクトオーナーやUXデザイナがAIツールでプロトタイプを作る 議事録・仕様書・設計メモといったドキュメント系の成果物もAIで作成しgitで管理する 特にバイブコーディングの広がりで、エンジニア以外もソースコードの形で成果物を作ることが増えました。弊社では AIが文脈を理解しやすいように、プロダクトのソースコードだけでなくデザイン成果物や設計ドキュメント、意思決定の経緯などもGitやGitHubに集約しています 。こうしてソースコードとドキュメントの両面から、 Gitリポジトリを触るエンジニア以外のメンバー が増えてきています。 このとき、従来からGit/GitHubを使うエンジニア側と、新たに使い始めた側のそれぞれに悩みが生まれます。 エンジニア側 — 開発フローの説明や救援作業（作業支援、誤コミットの修正）など、エンジニア以外のメンバーが慣れるまでサポート負荷が高くなる 開発に参加するメンバー側 — Git/GitHubの作法や開発フローを学ぶ負担と、それを意識することによるアイデア具現化スピードの鈍化 「AIに任せればベストプラクティスが守られるのでは？」と思いきや、そうでもありません。最近のAIモデルはGitやGitHubの良い作法を知っていますし、インターネットを探せば素晴らしいスキルも多々あります。しかし、開発するプロダクトの特徴やフェーズ、チームの大きさなどに応じて、現場に適した開発フローは様々であり、そこに開発チームの工夫が表れます。だからこそ、 自分のチームに適した開発手順を言語化してスキルに固める 必要がありました。 本記事では、エンジニア以外のメンバーも含む開発チームで、バイブコーディングの速さや気軽さも尊重しつつ、GitやGitHubをお行儀よく活用した開発フローを実現するために私が作り育てたClaudeスキルを題材に、その設計思想と中身、実際の使い勝手を ニールセンのユーザビリティ10原則 に照らし合わせて紹介します。 ※本記事は Claude Code の Skill 機能 を前提としています。また、 /d の動作には git コマンドと GitHub CLI （ gh コマンド）がセットアップ済みであることが必要です。 目次 はじめに 設計の3本柱 /d スキルの構造 動かしてみる：2つの典型シナリオ スキル改善の経緯と考え方 おわりに 設計の3本柱 /d の d は develop からとっています。 このスキルの設計には3つの軸があります。共通するのは、 作業者が意識して開発フローに合わせるのではなく、スキルを使っているだけで自然にルールを守れる という発想です。 A. バイブコーディングの手を止めない アイデアを高速に具現化する人の手を、複雑な開発プロセスで遅くしない。 お行儀のためのチェックリストや規約を増やすほど、利用者は「考える前に手順を思い出す」モードに入ります。これは思いつきを高速に形にするUXデザイナやプロダクトオーナーには致命的です。 /d スキルは 思考のリズムを止めない ことを最優先にします。 具体的には、手順を覚えてもらうのではなく スキル側がすべて代行する 設計にしました。たとえば、利用者が /d issue 42 と打つことでIssueに着手するときの定型作業を実行し、作業ブランチ作成・push・方針コメント投稿まで自動で走ります。 B. 使いながらGit/GitHubの作法に慣れる 細かい作法を習ってから使うのではなく、使いながら徐々に作法を体得する。 ブランチ・コミット・PR・rebase…とGitの概念を最初に全部説明されると、それだけで利用者は挫折します。一方で「教えなくていい」とすると、利用者はずっと作法を知らないまま、エンジニアの救援が必要な状態が続きます。 /d スキルは 「必要最低限のコマンドを使うだけで、結果としてお行儀よく作業できていた」 状態を作りつつ、 裏で何が起こったかは可視化する 設計にしました。 /d issue 実行時に「ブランチを作りました」「PRを作成しました」とログが出るので、利用者は使い続けるうちに「これはブランチを切っていたのか」「これがDraft PRか」と自然に理解していきます。また、issueやcommitなど重要な用語はGit/GitHubのエコシステムに合わせることで、エンジニアと同じ言語で開発に参加できるようにしています。 C. 覚えなければならない知識を減らす 使う側が頭の中に抱える「知識量」をできる限り減らす。 利用者の負担は 「次に何のコマンドを打つか」「どのスキルを呼ぶか」を毎回思い出すこと にあります。これを減らすために2つの仕掛けを入れました。 個別スキルではなくサブコマンド方式 — /d todo /d issue /d commit …といった操作を /d 1つのスキルに統合することで、利用者は最低限 /d だけ覚えればよく、 /d 42番のIssueに着手 のように自然言語で意図を伝えるだけでも適切なサブコマンドが実行されます 次のアクションは選択肢で提示 — スキル実行の終わりには必ず次の候補を出すことで、利用者は「次に何をすればよかったっけ」と考えずに済みます（後述する「再生より再認」） 結果として、利用者が頭に抱える「Git作法 + コマンド体系 + チーム運用ルール」の知識セットが大幅に圧縮されます。 覚えるべきは /d という入口だけ という状態が、参加ハードルを最小化します。 /d スキルの構造 スキル本体は ~/.claude/skills/d/SKILL.md 1ファイルです。フロントマター + サブコマンドごとの手順記述で構成されます。全文は以下に折りたたんで載せておきます。 SKILL.md 全文（クリックで展開） --- name: d description: GitHub Issue・Pull Request・ブランチ操作・コミット等の作法を定義した開発ワークフロースキル argument-hint: " < todo |new|issue|commit|pr|review|improve|help> [args...]" allowed-tools: Bash, Agent, Read --- GitHub を起点とした開発ワークフローをサブコマンドを指定して実行する。引数なしで ` /d ` と実行された場合は ` /d help ` として動作した上で、次の行動を提案する。 サブコマンドが指定されずに文が続く場合（例: ` /d 42番のIssueに着手して ` ）は、テキスト内容から利用者の意図を解釈し、適切なサブコマンドにマッピングして実行する。利用者は厳密なサブコマンド名を覚えていなくてもよい。 ## 出力ルール ### yes/no 質問 AIによる「〜してよいですか？」「〜しますか？」のような closed questionや許可確認の末尾には ` (y/n) ` を付け、ユーザの回答負荷を軽減する。「他に修正はありますか？」のような実質的Open Questionには付けない。 ### 表・箇条書きへの識別子付与 表・箇条書き・選択肢など、複数項目が並ぶ出力には必ず連番や記号の識別子を振る。Issue番号やPR番号など既存の識別子がある場合はそれを使い、無い場合は左端に ` No ` 列を追加する。これにより、後の会話でユーザが番号で行を指定できるようにする。 ### 次のアクションの提示 サブコマンドの終わりには、可能な限り次のアクションの候補を選択肢として提示する。利用者に「次に何をすればよいか」を思い出させるのではなく、提示された選択肢から選ばせる（再生より再認）。 ## 不満・改善提案の案内 利用者が ` /d ` スキルの挙動に不満を表明した場合: ` /d improve <内容> ` でスキル改善Issueを起票する。 ## 共通ルール ### 並列実行 依存関係のない複数のコマンド・API呼び出しは常に並列実行する。逐次実行しない。独立したコマンドを見つけたら積極的に並列化する。 ### ブランチ切り替え前の確認 ` git checkout ` の前に ` git status --porcelain ` で未コミット変更を確認する。変更がある場合は選択肢を提示: 1. **コミットして続行** 2. **worktree で並列作業** — ` git worktree add ../<リポ名>-<新ブランチ> -b <新ブランチ> origin/main ` → 別セッションを案内 3. **中断** ### main 最新取り込み 作業ブランチで ` /d issue ` （既存ブランチ checkout 時）または ` /d commit ` （push 前）に実行する。originのmainブランチに対する遅れを確認し、遅れがあれば ` git merge origin/main ` を提案する。 ### ブランチ命名規則 ` CLAUDE.md ` に命名規則の定義があればそれに従う。なければデフォルトとして ` <prefix>/<issue番号>-<英語kebab-case 5語以内> ` を使用する。prefix はIssueのラベル・内容から判断: - ` feat/ ` — 新機能 - ` fix/ ` — バグ修正 - ` nf/ ` — 非機能（インフラ等） - ` doc/ ` — ドキュメント - ` process/ ` — 開発プロセス関連（CI、Claudeスキル等） - ` misc/ ` — その他 Issue 番号がない場合は ` <prefix>/<英語kebab-case 5語以内> ` とする。 ### PR マージ確認 PR が Ready かつ最新コミットに対するレビューでマージ可能と判定されている場合、 ` gh pr merge <PR番号> --merge --delete-branch ` を提案する。適用タイミング: ` /d commit ` で Ready PR 作成後、 ` /d review ` で Ready 化後、 ` /d pr ` で Ready 化後。 ### レビュー実行 レビューは **Claude のレビュー用サブエージェント** で実行する。実装したコンテキストとは別のサブエージェントで実行することで、客観的な指摘を得る。 他人の PR をレビューする場合は先に対象ブランチを取得する。 チェックアウト前に元ブランチ名を退避し、ダーティーツリーでないことを確認する: ```bash ORIG_BRANCH=$(git branch --show-current) git status --porcelain # 出力ありなら未コミット変更あり ``` 未コミット変更がある場合は「ブランチ切り替え前の確認」を適用する。クリーンな状態を確認したら既存ローカルブランチを破壊しない方法で取得する: #### レビュー手順 1. ` COMMIT_SHA=$(git rev-parse HEAD) ` で SHA を取得。 ` git fetch origin main ` 後、 ` git diff origin/main...HEAD ` + ` git log origin/main..HEAD --oneline ` を取得。 ` OWNER_REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner) ` で owner/repo も取得 2. Agent ツールでレビュー用サブエージェントを起動する（ ` run_in_background: true ` ）。プロジェクトの設計基準やレビューガイドライン（ ` CLAUDE.md ` 、レビュー用エージェント定義、 ` docs/ ` 配下のガイドライン等があれば参照）に従ってレビューさせる。プロンプトに ` diff ` , ` commits ` , ` commit_sha ` , ` owner_repo ` , ` pr_number ` , ` pr_author ` , ` is_own_pr ` , ` is_draft ` , ` post_to_pr=false ` , ` defer_ready=true ` を渡す 3. 完了を待ち、結果を会話に表示（指摘一覧 + 総合判定） 4. 自分の PR の場合は各指摘の妥当性を評価する 5. ` post_to_pr=true ` の場合は次の「PR への投稿」を実行 #### PR への投稿 ( ` post_to_pr=true ` ) skill 側で投稿する（レビュー用サブエージェントは二重投稿回避のため ` post_to_pr=false ` ）: - **総評コメント**: ` gh pr review <PR番号> --comment --body "<本文>" ` （自分の PR）/ ` --approve ` / ` --request-changes ` （他人の PR） - **インラインコメント**: ` gh api repos/{owner}/{repo}/pulls/<PR番号>/comments ` を使用。各コメントに ` commit_id ` (= ` COMMIT_SHA ` ), ` path ` , ` line ` , ` side ` が必須 投稿後、自分の Draft PR でマージ可能（高指摘なし）なら Ready 化: 1. PR タイトルから ` WIP: ` 削除 2. 本文を ` Summary / Related Issue / Test plan ` テンプレートに更新（ ` Closes ` / ` Refs ` は「Related Issue とクローズ判定」に従う） 3. ` gh pr ready <番号> ` ### 変更確認 ` git status --porcelain ` 、 ` git diff ` 、 ` git diff --cached ` を3つ並列実行する。変更がなければエラー。 ### ステージング判断 以下の懸念がないか確認する: - ` .env ` 、クレデンシャル系（ ` credentials.json ` 、 ` cred-* ` 、 ` *.pem ` 、 ` *.key ` 等） - ` .gitignore ` すべきファイル（ ` node_modules/ ` 、 ` dist/ ` 、 ` __pycache__/ ` 、 ` .venv/ ` 等） - ブランチ名から推測される作業内容と無関係なファイル 懸念がなければ全ファイルを自動ステージング（確認不要）。懸念があれば明示してユーザーに確認する。 ### コミットメッセージ生成 変更内容から日本語で簡潔に自動生成する（確認不要）。ブランチ名に Issue 番号があれば ` #<番号> ` を含める。 ## サブコマンド ### ` /d todo ` 自分が対応すべきものを表示する。 現在作業中のタスクがあるかどうかと、GitHub上でアサインされたIssue、メンション、レビュー依頼を確認する。 1. **2つを並列実行**: - (A) gitコマンドで現在の作業状況を確認 ` git fetch origin && git branch --show-current && git status --porcelain ` - (B) ghコマンドでGitHubを確認。GraphQL で一括取得: ```bash OWNER_REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner) gh api graphql -f query="{ assignedIssues: search(query: \"repo:${OWNER_REPO} assignee:@me is:open is:issue\", type: ISSUE, first: 20) { nodes { ... on Issue { number title labels(first: 5) { nodes { name } } updatedAt } } } reviewRequested: search(query: \"repo:${OWNER_REPO} review-requested:@me is:open is:pr\", type: ISSUE, first: 20) { nodes { ... on PullRequest { number title author { login } updatedAt } } } mentions: search(query: \"repo:${OWNER_REPO} mentions:@me is:open\", type: ISSUE, first: 20) { nodes { ... on Issue { number title updatedAt } } } myOpenPRs: search(query: \"repo:${OWNER_REPO} is:open is:pr author:@me\", type: ISSUE, first: 20) { nodes { ... on PullRequest { number headRefName isDraft } } } }" ``` 2. **fetch 完了後の確認**: - 現在のブランチが main なら ` git rev-list HEAD..origin/main --count ` で同期状態を確認。作業ブランチなら ` gh pr view --json number,title,state,mergedAt,url ` で PR 状態を確認 - アサイン済み Issue について ` git branch -r ` を1回実行し、各 Issue 番号に対して ` origin/*/<issue番号>-* ` のパターンでブランチを探す → ` myOpenPRs ` から PR 有無を判定 → 未着手 / ブランチあり / PR #番号 (Draft|Ready) 3. **出力フォーマット**: ``` ## 現在のブランチ - ⚠️/✓/🔧 の状態表示 ## アサイン済み Issue | # | タイトル | 状態 | ラベル | 更新日 | ## レビュー依頼 | # | タイトル | 作成者 | 更新日 | ## メンション | # | タイトル | 更新日 | ``` 4. **次のアクション提案**: 優先度の高い順に次にやるべき作業を提案する。「main に戻りましょう」は提案しない（作業ブランチで ` /d issue ` を実行すれば自動的に origin/main ベースのブランチが作成されるため） ### ` /d new <タイトル> ` 新しい Issue を起票する（自分が取り組むとは限らない）。 1. 引数を要約してタイトルにする（なければユーザーに聞く） 2. ` gh issue list --state open --json number,title ` で既存の類似 Issue をチェック 3. 説明文の案を生成してユーザーに提示（経緯・現状・期待効果を含める） 4. ` gh label list --json name,description ` で適切なラベルを判定 5. ` gh issue create --title "..." --body "..." --label "..." ` で作成 6. URL を表示 7. **次のアクションを必ず選択肢として提示**（省略不可）: 1. 自分をアサインして今から取り組む → ` /d issue ` の処理を続行 2. 自分をアサインして作業に戻る → ` gh issue edit <番号> --add-assignee "@me" ` のみ 3. 他の人をアサインする（対象者を指定） 4. アサインせず終了 ### ` /d issue <番号またはURL> ` （エイリアス: ` /d i ` ） 既存 Issue に自分が取り組む。ブランチ作成・プッシュで着手を宣言してから方針コメントを投稿する。 1. Issue 番号を特定し、内容取得 + 自分をアサイン: ```bash gh issue view <番号> --json title,body,labels,assignees gh issue edit <番号> --add-assignee "@me" ``` 2. ` git fetch origin && git branch -a --list "*/<issue番号>-*" ` で既存ブランチを確認: - **あり**: 他人のコミットがあればユーザーに確認。なければチェックアウト + 「main 最新取り込み」を実行 - **なし**: Issue からブランチ名を生成（「ブランチ命名規則」参照）。**確認不要で** 作成・push する: ```bash git checkout -b "<prefix>/<番号>-<説明>" origin/main git push -u origin HEAD ``` 3. 方針・実装計画をユーザーに提示 → 承認後 ` gh issue comment ` で投稿（投稿の確認不要） **ここがポイント**: ブランチを push してIssueコメントを残すことで、他メンバーに「自分が #<番号> に着手中」が見えるようになる。重複着手を未然に防ぐ。 ### ` /d commit ` 変更をコミット・プッシュし、PR が未作成なら Draft PR も作成する。 **ブランチ判定:** - **`main` の場合**: 変更内容から prefix を判断し、ブランチ名を生成 → ` git checkout -b "<prefix>/<説明>" ` → 次の手順へ - **作業ブランチの場合**: そのまま次の手順へ **手順:** 1. 変更確認（共通ルール） 2. ステージング判断（共通ルール） 3. ブランチ名から Issue 番号を抽出（ ` feat/123-xxx ` の ` / ` の後の数字） 4. コミットメッセージ生成 → ` git add && git commit ` 5. main 最新取り込み（共通ルール） 6. ` git push -u origin HEAD ` 7. ` gh pr list --head <ブランチ> --json number,title,isDraft,url,author ` で PR 確認 8. **レビュー実行**（ ` is_own_pr=true ` , ` post_to_pr=true ` ）: - **PR がない場合**: ` /d pr ` に従ってDraft PR 作成 → レビュー実行 — 初回レビューは精度優先 - **PR が既存の場合**: 追加コミットの差分をレビュー 9. PR マージ確認（共通ルール） 10. 結果表示: コミットハッシュ・メッセージ、プッシュ先、PR URL、レビュー結果 ### ` /d pr ` Pull Requestを作成。または、作成済のPRに対して必要なアクションをする。 1. ブランチが ` main ` ならエラー 2. ` gh pr view --json number,title,isDraft,url ` で既存 PR 確認 3. **PR あり**: PR コメント確認 → 未対応あれば対応 4. ` git fetch origin main ` → ` git log origin/main..HEAD --oneline ` + ` git diff origin/main...HEAD --stat ` で差分取得 5. PR タイトル（70文字以内）と本文を生成（ ` 概要 / 関連Issue / やったこと / やっていないこと ` 。 ` 関連Issue ` は共通ルールに従い ` Closes ` / ` Refs ` ） 6. ` git push -u origin HEAD ` → PR なしなら Draft 作成、あればタイトル・本文を更新 7. レビュー実行（ ` is_own_pr=true ` , ` post_to_pr=true ` , ` effort=high ` ）→ 結果表示 8. URL 表示 9. PR マージ確認（共通ルール） ### ` /d review ` 作業ブランチの変更をレビュー。PR があればレビューとして投稿可能。 1. ブランチが ` main ` ならエラー 2. ` gh pr view --json number,title,url,isDraft,author ` で PR 確認。 ` gh api user --jq .login ` と ` author.login ` を比較して ` is_own_pr ` を決定 3. レビュー実行（ ` is_own_pr=<判定> ` , ` is_draft=<取得値、なければtrue> ` , ` post_to_pr=false ` , ` effort=high ` ）→ 結果表示 4. **PR あり**: 投稿するか確認 → 投稿する場合は「PR への投稿」を実行（ ` post_to_pr=true ` ）。Draft かつマージ可能なら Ready 化が走る 5. PR マージ確認（共通ルール） ### ` /d improve <改善内容> ` ` /d ` スキル自体の改善提案を Issue 起票する。 1. 引数があればそれを改善内容にする。引数がない場合は直前の会話の文脈（不満や違和感の表明、うまくいかなかった操作など）から推測する 2. 改善内容をもとに簡潔な Issue タイトル（日本語）を生成 3. Issue を作成: ```bash gh issue create --title "<タイトル>" --body "$(cat <<'EOF' ## 改善内容 <スキル改善内容> ## 代替案 <claudeの設定など、スキル自体の改善以外で実現可能な代替案> EOF )" ``` 4. 作成した Issue の URL を表示 ### ` /d help ` 以下をそのまま出力する: ``` ## 開発プロセス ### (1) アサインされたタスクに取り組む 1. `/d` で自分のタスクを確認する 2. `/d issue <番号>` で Issue に着手する（アサイン→ブランチ作成→方針コメント） 3. 実装する 4. `/d commit` でコミット・プッシュ・PR作成 5. `/d review` でレビュー・Ready化 ### (2) 新しい課題を起票する `/d new <タイトル>` で Issue を作成する。自分で取り組むかどうかはその場で選択できる。 ### (3) Issue を立てずに実装する 1. 実装する（main ブランチ上でも `/d commit` が自動でブランチを作成する） 2. `/d commit` でコミット・プッシュ・PR作成 3. `/d review` でレビュー・Ready化 ### (4) このスキルの改善リクエスト `/d improve <不満点や改善案>` で改善提案を Issue 起票する。 ## コマンド一覧 | コマンド | 説明 | |---|---| | `/d` | `/d help` と同じ（サブコマンド省略時） | | `/d todo` | 自分のアサインタスク・メンション・レビュー依頼を一覧 | | `/d new <タイトル>` | 新規 GitHub Issue を起票 | | `/d issue <番号>` (`/d i`) | 既存 Issue に着手（アサイン→ブランチ作成→方針コメント） | | `/d commit` | コミット→push→Draft PR作成→AIレビュー | | `/d pr` | PR 作成・更新 | | `/d review` | 作業内容のレビュー | | `/d improve <内容>` (`/d imp`) | スキル自身の改善提案を Issue 起票 | | `/d help` | このヘルプを表示 | ## ヒント - 厳密なサブコマンド名を覚えていなくても、`/d 42番のIssueに着手して` のように自然言語で指示すれば適切なサブコマンドが実行される - 困ったら `/d` だけ打って、表示された選択肢から選べばよい ``` サブコマンド一覧 サブコマンド 役割 /d （引数なし） /d help と同じ /d todo 自分のアサインタスク・メンション・レビュー依頼を一覧 /d new <タイトル> 新規Issueを起票 /d issue <番号> 既存Issueに着手（アサイン→ブランチ作成→push→方針コメント） /d commit コミット→push→Draft PR作成→AIレビュー /d pr PRの作成・更新 /d review 作業内容のレビュー /d improve <内容> スキル自身の改善提案をIssue起票 /d help 全コマンド一覧と典型フローを表示 個別スキルではなくサブコマンド方式にしたことで、利用者は 「困ったら /d に続けてやりたいことを伝える」だけ で、スキルで規定したルールに則れます。 主役は /d todo / /d issue / /d commit / /d review の4つ 主役サブコマンドは、 作業者がもともと意識している作業アクション に対応します。 自分のタスクを確認する 着手する 成果物を提出する レビューする いずれも Git/GitHubとは無関係に作業過程に存在するアクション です。これらを主役に据え、ブランチ作成・PR作成・mainブランチ取り込みといったGit/GitHub起因の操作は内側に隠してAIが自動化します。 さらに /d todo はIssueのアサイン情報に基づいて着手すべきIssueを提案し、 /d commit はコミットからPR作成、AIレビューまでまとめて実行するため、 典型フローで利用者が実際に打つのは /d todo → /d commit の2つで済むことも多い です。 動かしてみる：2つの典型シナリオ 入口は2通りありますが、 どちらも最後は /d commit に合流し、PRベースの開発フローが進む のがポイントです。 シナリオA：Issue駆動で開発を進める場合 UXデザイナの佐藤さんに「ログイン画面の入力欄の余白を調整してほしい」という Issue #58 がアサインされた。 Step 1: /d todo で確認し、そのまま着手する > /d todo スキルは「現在のブランチ・アサイン済みIssue・レビュー依頼・メンション」を並列取得して整形表示し、 最後に「次に何をすべきか」まで提案します 。 ## 現在のブランチ - ✓ main（クリーン） ## アサイン済み Issue | # | タイトル | 状態 | ラベル | |----|---------------------------------------|--------|--------| | 58 | ログイン画面の入力欄の余白を調整したい | 未着手 | feat | （レビュー依頼・メンションはありません） --- 未着手の Issue が1件あります。優先度の高い #58 から着手しますか？ （アサイン → ブランチ作成 → push → 方針コメント まで実行します） (y/n) /d todo は一覧を並べて終わりではなく、 「未着手の #58 から着手しますか？」と次の一手まで提案 します。利用者は表を眺めて「次に何をしよう」と考える必要がありません。ここで y と答えれば、着手処理がそのまま走ります。 # 「はい」と答えた後にスキルが実行する内部処理 gh issue edit 58 --add-assignee "@me" git checkout -b "feat/58-login-margin" origin/main git push -u origin HEAD gh issue comment 58 --body "<実装方針>" ブランチがpushされた瞬間、GitHubの他メンバーには「佐藤さんが #58 着手中」が見えます。 これだけで重複着手を大きく減らせます。 着手の入口は2通り、どちらでもよい — Issue番号が最初からわかっているなら、 /d todo を経由せず /d issue 58 を直接打っても同じ着手処理に入ります。「 /d todo の提案に乗る」か「 /d issue を直接打つ」かは、利用者が好きな方を選べます。 Step 2: 実装 → /d commit 佐藤さんはClaude Codeに実装を任せ、完了したら /d commit を実行。 コミット → push → Draft PR → AIレビュー → Ready化 → マージ → Issueクローズ までが一気に流れます。 結局、利用者が打つのは /d todo （提案に乗って着手）→ /d commit の実質2コマンドだけ。ブランチ名やコミットメッセージ、PR本文を書く場面はありません。 補足：Issueがまだ無いときは /d new で起票する シナリオAはアサイン済みの Issue #58 から始めましたが、そもそも取り組みたいことがまだIssueになっていないこともあります。その場合は /d new に概要を渡すだけで起票できます。 > /d new ログイン画面の入力欄の余白を調整したい スキルは既存の類似Issueを確認したうえで、タイトル・説明文・ラベルの案を生成して起票し、作成後に 「誰が取り組むか」を選択肢で提示 します。 Issue #59 を作成しました： https://github.com/<owner>/<repo>/issues/59 続けてどうしますか？ 1. 自分をアサインして今から取り組む（そのまま着手処理へ） 2. 自分をアサインして後で取り組む 3. 他の人をアサインする 4. アサインせず終了 1 を選べば、そのまま /d issue 相当の着手処理（アサイン → ブランチ作成 → push → 方針コメント）に流れます。 「起票 → 着手」がコマンドを打ち替えずに一本でつながる のがポイントです。起票だけして他の人に任せたい（ 3 ）、あとで自分でやる（ 2 ）といった分岐も、その場で選ぶだけで済みます。 また /d new は、機能追加のようなきちんとしたIssueだけでなく、 「このドキュメントを直してほしい」「Claudeのスキルを修正して」といったちょっとした作業依頼 にも気軽に使えます。口頭やチャットで流れがちな細かい依頼もIssueとして残り、依頼のハードルが下がります。さらに 受けた側が /d issue で着手するときには、AIがIssue本文（背景・経緯・期待する結果）を文脈として読み取れます 。チャットの断片的なやり取りと違い、要件がまとまっているぶん、AIは意図を汲んだ実装や方針コメントを返しやすくなります。これは冒頭で触れた 「AIが文脈を理解しやすいようにGit/GitHubへ集約する」 流れに、気軽な起票がそのまま乗る形です。 シナリオB：Issueを立てず、思いついた改善案をいきなり作り始める場合 UXデザイナの佐藤さんは、ふと思いついたUIの改善案をその場でClaude Codeに作らせてみた。Issueも立てず、ブランチも main のままローカルに修正案ができあがっている。仕上がりが良かったので、そのまま /d commit を実行する。 > /d commit このとき、スキルは変更内容を確認し、 変更内容から適切なブランチ名（ fix/update-signup-form-warning-message など）を判断 自動でブランチを切ってから コミット そのブランチをpushし、Draft PRを作成 続けて AIレビューが走り 、変更内容に問題がなければReady化 シナリオAと同じく、 /d commit の先はDraft PR作成からAIレビュー・Ready化まで一気に流れます。佐藤さんは「ブランチを切り忘れた」「Issueを立て忘れた」と慌てる必要がなく、思いついた改善案を形にすることだけに集中できます。 「アイデアを止めずに作り、後から正しい形に整える」 ── バイブコーディングのリズムを保ったまま、結果的にお行儀の良い形に着地します。 スキル改善の経緯と考え方 /d は最初から今の姿だったわけではありません。初期はもっと細かく「ブランチを作る」「Pull Requestを作る」といった Gitの操作にも1つずつコマンドを紐づけており、個々の操作をAIで補完しているだけでした。エンジニアにとっては違和感がなくとも、エンジニア以外の利用者から見ると どのコマンドを打つか選ぶ時点でGitの知識が必要 で、開発フローの作法を覚える負担が残っていました。 そこで 「ツールではなく目的中心でスキルのあり方を決める」 ことを強く意識し、使いやすさを追求して改善を重ねました。判断軸として参照したのが、UX設計の古典である ヤコブ・ニールセンのユーザビリティ10原則 です。スキル開発は「自分が便利な機能を足す」方向に流れがちですが、10原則に照らすことで「これは利用者目線の仕様になっているか？」を問い直せました。 10原則は以下のとおりです（和訳は本記事での表記）。 Visibility of system status / 状態の可視性 Match between the system and the real world / 現実世界との調和 User control and freedom / ユーザーコントロールと自由 Consistency and standards / 一貫性と標準 Error prevention / エラー予防 Recognition rather than recall / 再生より再認 Flexibility and efficiency of use / 柔軟性と効率性 Aesthetic and minimalist design / 最小限デザイン Help users recognize, diagnose, and recover from errors / エラー回復 Help and documentation / ヘルプとドキュメンテーション この章では、特に大きく効いた 4つの改善 を、対応する原則とともに紹介します。 改善1：コマンドを「Git操作」から「作業アクション」へ（原則2 現実世界との調和） 最大の改善が、コマンド体系そのものの組み替えです。 Before — ブランチ作成・コミット・PR作成…と、Git/GitHubの操作を利用者が1つずつ呼び出す体系 After — /d todo （見る）・ /d issue （着手）・ /d commit （提出）・ /d review （レビュー）の4つ。ブランチ作成やPR作成はこの内側に隠れる 原則2「現実世界との調和」は、 利用者が現実世界から類推するイメージにシステムを合わせよ という原則です。タスクを見る・着手する・成果物を提出する・レビューする ── いずれもGit/GitHubに関係なく開発の作業過程に存在するアクションであり、利用者が説明されなくてもする行動です。ここに揃えたことで「開発ツールの使い方を学ぶ」という壁が解消されました。 改善2：「誰が何をやっているか」が自然に見える（原則1 状態の可視性） 原則1「状態の可視性」は、 システムの状態を利用者に常に見えるようにせよ という原則です。 /d ではこれを個人の画面にとどめず、 チームに対する作業状況の可視化 に広げました。改善1で「着手」の内側に束ねた一連の操作が、そのまま 着手宣言プロトコル として機能します。 /d issue 58 を実行した時点で、 アサイン + 作業ブランチのリモートpush + 方針コメントの投稿 が走ります。コミットがまだ無くても「私が #58 やってます」が周囲に見えるようになります。地味ですが、これだけで 実装を二重に進めてしまう事故 を大きく減らせます。自分から「やってます」と声を上げなくても着手した時点で自然に共有され、チーム全体での作業状況が見えやすくなります。 改善3：誤操作は注意ではなく仕組みで防ぐ（原則5 エラー予防） 原則5「エラー予防」は、 丁寧な注意喚起よりも、そもそもエラーが起きない設計を優先せよ という原則です。Gitを使っていて起きがちな失敗に対して、「気を付けてね」と促すのではなく仕組みで潰します。 /d スキルを使いながら取り入れた予防の仕組みをいくつか紹介します。 # 起きがちな失敗 スキルでの解決 1 同じ内容のIssueを重複起票 起票前に既存Issueとの類似をチェック 2 mainで作業して直push 変更を検知し、自動でブランチを切ってからコミット 3 test tmp 等でブランチ名が乱立 Issue・変更内容から命名規則に沿って自動命名 4 同じIssueを別ブランチで重複着手 着手時に既存ブランチを確認、他人のコミットがあれば確認 5 .env ・ node_modules 等を誤commit ステージング前に自動検知して確認 6 Issueと無関係なファイルが混入 ブランチ名から推測した作業内容と照合して警告 7 未コミット変更を抱えたままcheckout 切り替え前に確認し、コミット/中断を提示 8 ローカルのmainが古いまま進めてconflict地獄 作業着手時やpush前にmainとの差を自動チェックし取り込みを提案 9 Issue・コミット・PRの説明の作文が面倒で省略・雑になる 変更内容からAIがタイトル・本文・コミットメッセージ・PR説明を自動作文 改善4：思い出させない・迷わせない（原則6 再生より再認） 原則6は、認知科学でいう 「再生（recall）より再認（recognition）の方が遥かに楽」 という性質に基づく原則です。「次に何をすべきか」を利用者が思い出す（再生）必要をなくし、 提示された選択肢から選ぶ（再認） だけで正しい手順を歩めるようにします。 「次にやること」を選択肢で提示する サブコマンドの終わりには、必ず 次の候補アクションを選択肢で提示 します。 /d todo の最後 → 優先度の高い順に次のタスクを提案 /d new で起票後 → 「自分をアサインして取り組む / アサインのみ / 他の人にアサイン / アサインしない」 /d commit のレビュー完了後 → 「マージしますか？ (y/n)」 利用者は「次に何をすればよかったっけ」と考える必要がなく、選ぶだけで正しい手順に乗れます。 リスト出力に必ず識別子を振る 「選ぶだけ」のやり取りを支えるため、表・箇条書き・選択肢など複数項目が並ぶ出力には、 必ず連番や記号の識別子を振る ルールにしました。Issue番号のような既存IDがあればそれを使い、無ければ連番を振ります。たとえば実装前に手順の計画を出させると、こうなります。 実装計画: 1. 入力欄コンポーネントの余白を変数化 2. ログイン画面へ適用 3. モバイル表示のスタイル調整 4. 他画面のフォームへ横展開 5. 不要になった旧スタイルの削除 どこまで進めますか？ 地味ですが効果は大きく、利用者は 「一旦3まで進めて」「4と5は不要」 のように番号だけで指示できます。AIとのチャットでは対象を言葉で説明し直したり長い引用をコピペしたりが負担になりがちですが、識別子があるとやり取りが一気に短くなります。 10原則ダイジェスト：残りの原則も設計に対応づける 改善1〜4で使った原則（1・2・5・6）以外も、 /d の設計判断のあちこちに対応しています。残り6つをダイジェストで紹介します。 原則3 ユーザーコントロールと自由 — Issue起点のフローに限定せず、mainでの思いつき着手も許容。破壊的操作の前には必ず (y/n) 確認 原則4 一貫性と標準 — issue commit などの用語は技術側に合わせ、利用者の用語習得やエンジニアとの意思疎通を重視 原則7 柔軟性と効率性 — 初心者は /d todo の提案に乗るだけで着手まで進み、慣れたら /d issue を直接打つ・エイリアス（ /d i ）を使うなど効率化できる。さらに /d improve でスキル自体を進化させられる 原則8 最小限デザイン — 覚えるべきコマンドを少なくし、自然言語でも動くようにすることで、スキルの使い方をシンプルに 原則9 エラー回復 — ワークフロー操作をAIが実施することで、エラー時もAIが能動的に調査・回復できる。使いづらさがあれば /d improve で不満を改善案としてIssue化できる 原則10 ヘルプとドキュメンテーション — /d help で全コマンドと典型フローを表示 おわりに 本記事では、Git/GitHubを使った開発フローをエンジニア以外のメンバーと協働して進めるためのスキルについて紹介しました。エンジニア以外のメンバーとともに開発するチームで、 全員が安心して開発できる環境づくりの一助になれば幸いです。 「こうしたらもっと良くなる」「自分のチームではこうしてる」などがあれば、是非コメントください！