Linux初心者がAzure仮想マシンでHTTPサーバーを構築した話 --> こんにちは！新卒でサイオステクノロジーに入社したごままぐろです。 本記事では、Linux初心者が研修で得た学びを以下の構成でご紹介します。LinuxはITパスポートなどの資格勉強で少し知っている程度だったのですが、この度新卒研修の一環としてLinux仮想環境でのサーバ構築を行いました。 これからLinuxを学ぶ方の参考になれば幸いです。 Linuxについて Linuxとは LinuxはWindowsやMacのようなOS（Operating System）の一種です。OSS（Open Source Software）として公開されているため、世界中の開発者が自由にプログラムの中身を確認したりカスタマイズできます。 厳密にいえば、「Linux」とはOSの核心である「カーネル」のことを指すようです。しかし実際には、カーネルに独自の管理ツールやアプリケーションを組み合わせた「Linuxディストリビューション」のことをLinuxと呼ぶことが多いそうです。 有名なLinuxディストリビューションには以下のものがあります。 RedHat系： RHEL、AlmaLinux など Debian系： Debian、Ubuntu など Linuxの特徴 Linuxには以下のような特徴があります。 基本的に文字ベースで操作する データをディレクトリとファイルの入れ子構造で管理する ユーザごとに権限を設定できる 私の場合、このあたりの特徴を掴むのに時間がかかりました。今も完全に理解できているか分からないのですが、私なりの言葉で簡単に説明したいと思います。 LPI-Japanという団体が初学者向けに 「Linux標準教科書」 という資料を公開しているので、正確な情報を知りたい方はそちらを参照してみてください。 １．基本的に文字ベースで操作する Linuxでは、キーボードで命令（コマンド）を入力するCUI（Character User Interface）での操作が基本です。 Linuxのコマンドは基本的に「コマンド」「オプション」「引数」で構成されます。 同じ操作でも、ディストリビューションによっては別のコマンドやオプションが存在する場合があるため、注意が必要です。 ２．データをディレクトリとファイルの入れ子構造で管理する Linuxでは、データはディレクトリとファイルの入れ子構造で管理されます。 ディレクトリはフォルダのようなもので、ファイルを整理するための入れ物です。ディレクトリの中にさらにディレクトリを作ることもでき、これを入れ子構造と呼びます。 ファイルを操作する時には、ファイルの住所（パス）を指定する必要があります。パスには、最上位（/ルートディレクトリ）からの絶対パスと、現在のディレクトリからの相対パスがあります。 絶対パス： /home/username/newdir/file1.txt 相対パス：(現在の位置が/home/usernameの場合) newdir/file1.txt ３．ユーザごとに権限を設定できる Linuxには「ユーザ」という概念があります。ユーザには、人がログインして操作を行うためのものの他に、人がログインできず内部でプログラムを動かすためのものもあります。 Linuxでは、ユーザごとに権限を設定できます。権限には、読み取り（r）、書き込み（w）、実行（x）の3種類があります。 例えば、ファイルに何か書き込みたいと思っても、自身が操作するユーザにその権限がなければ書き込むことはできません。 権限を設定するコマンドもあるため、必要に応じて割り当てたり変更する必要があります。 本章の内容は以上です。 次章では、実際にLinux仮想環境を用意してサーバ構築を行った手順をご紹介します。 Linux仮想環境でのサーバ構築 仮想マシン(AzureVM)の用意 Linuxは、コンピュータ（ハードウェア）の機能を管理しプロセスとの仲立ちを行うカーネルと、カーネルに人間の出した命令（コマンド）を翻訳し伝えるシェルで構成されています。 実際にLinuxを動かして学ぶには、コマンドを出す対象となるコンピュータが必要です。 しかし私が現在使っているコンピュータはWindowsという別のシステムが管理しているため、Linuxのコマンドを書いても通じません。 そのため今回は仮想化されたコンピュータである「Azure VM（Virtual Machines）」というクラウドサービスを利用して仮想環境を構築しました。 仮想マシンOSには、「Red Hat Enterprise Linux (RHEL) 9.4」を選択しました。 Windows環境を維持したままLinuxを実際に操作する方法は他にもいろいろあるので、ご自身のパソコンやその他条件に応じて選択することをおすすめします。 仮想マシンにSSH接続 仮想マシンを作成したら、次はそれに接続する必要があります。 今回はSSHという通信プロトコルを使って接続しました。 SSHは暗号化された通信を行うためのプロトコルで、今回のようにコンピュータが手元にない（リモート）場合でも安全に接続することができます。 SSH接続の手順は以下の通りです。 仮想マシン作成時に生成された秘密鍵を自分のパソコンに保存する ターミナル（コマンドプロンプト）を開き、以下のコマンドを実行して接続する ssh -i 秘密鍵のパス ユーザー名@IPアドレス 初回接続時には、ホストキーの確認が求められるので「yes」と入力 HTTP通信に必要なもののインストールと設定 作成した仮想マシンには最低限の機能しかないため、目的に応じて必要な部品や設定を追加する必要があります。 今回は、Webブラウザにアドレスを入力するとWebページが表示されるようにしたかったので、Apacheというものをインストールしました。 １．Azure Portalで受信ポート規則の変更 認証のため受信ポート22番（SSH）を許可する ソースは安全のため自分のIPアドレスに限定する ２．仮想マシン上でApacheのインストール sudo dnf install httpd ３．Apacheの起動と自動起動設定 ・サービスの起動 sudo systemctl start httpd ・自動起動の有効化 sudo systemctl enable httpd ４．RHELの内部ファイアウォールでHTTPトラフィックの許可 ・HTTPの許可 sudo firewall-cmd --add-service=http --permanent ・設定の反映 sudo firewall-cmd --reload ５．Azure Portalで受信ポート規則の変更 Webページを閲覧するため受信ポート80番（HTTP）を許可する ソースは自分のIPアドレスに限定する 表示するコンテンツの作成 Apacheのデフォルト設定では、「/var/www/html」ディレクトリにHTMLファイルを置くことで、Webページとして表示されるコンテンツを作成できます。 今回は、以下のコマンドで「index.html」を作成しました。 sudo vi /var/www/html/index.html Linuxでファイルを編集するには、viエディタなどのテキストエディタを使用します。 viエディタには実際に中身を編集するインサートモードと、ファイルの保存や終了などの操作を行うコマンドモードがあります。 慣れないうちは操作が難しく、何度かパニックになりました。   Webページの表示確認 Webブラウザに仮想マシンのIPアドレスを入力すると、作成したWebページが表示されます。 Azure Portalの受信ポート規則でソースを自分のIPアドレスに限定しているため、他のIPアドレスからはアクセスできません。 感想とまとめ 以上が今回のサーバ構築で行った内容でした。全くの初心者の私にとっては非常に充実した経験となりました。 実はこの後も様々な学習を続けており、現在は認証認可というもっと高度な設定に挑戦しています。余裕があれば現在取り組んでいる内容もまとめたいと思っているため、また機会があればよろしくお願いします。 長くつたない文章を最後までお読みいただき、ありがとうございました。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post Linux初心者がAzure仮想マシンでHTTPサーバを構築した話 first appeared on SIOS Tech Lab .

2026年6月11日（木）、12日（金）の2日間、AWS 麻布台オフィスにて AI 駆動型ハッカソンイベント「AWS GenAI Catapult! 」を開催いたしました。本イベントは、生成 AI 活用を前提にAmazon のイノベーション創出メカニズム「Working Backwards」手法を用いて顧客起点で生成 AI ユースケースを創出し、プロトタイプ開発まで行うコンテスト形式のイベントです。 前回 に続く2回目の開催となる今年は、創出したユースケースを AI コーディングエージェント「Kiro」でプロトタイピングし、アイデアを「動くもの」に変えるところまでを2日間で一気通貫に体験するという新たな挑戦を加えました。金融領域の13社12チーム（47名）の皆様にご参加いただき、活発な議論と創造的なアイデア創出、プロトタイプ開発、そして各社それぞれの工夫を凝らした内容で熱のこもった発表が行われました。本記事では、企画の背景から当日の様子、参加者の声までをお届けします。 前回開催からの進化 — アイデア創出から「動くプロトタイプ」へ 昨年7月の「AWS GenAI Catapult! 」は、Working Backwards によるアイデア創出を中心とし、プロトタイプの提示は任意（加点要素）、発表は初日から約3週間後に別日を設けて実施する形式でした。今年は昨今の生成 AI の進化に伴い次の3点を大きくアップデートして、「考える」から「作る」まで地続きで体験できるようにしたことが、今年最大の特徴です。 連続2日間で完結：学び・アイデア創出・開発・発表までを途切れさせずに2日間でやり切る構成に変更 Kiro によるプロトタイプ開発を本格導入：アイデアを構想で終わらせず、その場で動くアプリケーションとして形に 発表は「動くデモ」付き：プレスリリースに加えてプロトタイプのデモを披露 企画の背景 日本企業の生成 AI 活用の現状 — AI活用の方針は前進、しかし「使いこなし」はこれから 総務省の 令和7年版 情報通信白書 によると、日本企業で生成 AI の活用方針を「定めている」とした比率は 49.7% （前回の調査の 42.7% から増加）と着実に前進しました。一方で、調査した他国と比較すると依然として低い水準にとどまっています。実際の利用面でも、何らかの業務で生成 AI を利用している企業は日本で 55.2% 、「メールや議事録、資料作成等の補助」での利用は 47.3% と、いずれも他国より低い割合でした。導入に際しての懸念事項として日本企業が最も多く挙げたのは「 効果的な活用方法がわからない 」で、次いで社内情報の漏えい等のセキュリティリスク、ランニングコスト、初期コストが続きます。生成 AI を「どう自分たちの価値創出につなげるか」という具体的な適用イメージを描けていないことが、依然として大きな壁になっていると考えられます。 「業務効率化」の先へ — 顧客起点のイノベーションという課題 同白書では、生成 AI 活用による自社への影響について、日本企業は「 業務効率化や人員不足の解消につながる 」を最も多く挙げました。これに対し、米国・ドイツ・中国の3か国では「ビジネスの拡大」「新たな顧客獲得」「新たなイノベーション」を多く挙げる傾向が見られます。つまり日本では、生成 AI が業務効率化の手段にとどまりがちで、新たな顧客価値の創造へと踏み込めていない構図がうかがえます。金融業界でも、技術起点のアプローチに偏り、顧客価値創出に課題を抱えるケースは少なくありません。 「AWS GenAI Catapult! 」は、まさにこの「業務効率化の先」へ一歩踏み出すための場です。顧客起点でユースケースを発想し、その価値をその場で検証する体験を通じて、生成 AI 活用を効率化からイノベーション創出へと引き上げることを狙いました。 Amazon 流・顧客起点のイノベーション創出メカニズム「Working Backwards」 Amazon が実践してきたイノベーション創出のメカニズム「Working Backwards」手法 は、Amazon Echo、Amazon Prime、AWS などのサービス開発に活用されてきたアプローチです。顧客の理想的な体験から逆算してサービスを設計することで、顧客が本当に求める価値に焦点を当てた開発を可能にします。具体的には、企画段階から顧客体験をプレスリリースという形に詰め込むことで実現します。「Working Backwards」は知識として学ぶだけでは習得できません。実際にプレスリリースを書き、発表しフィードバックを受ける体験を通して、はじめて身につきます。 コーディングエージェントの進化が、「作る」のハードルを下げた 今年プロトタイプ開発まで踏み込んだ最大の理由が、AI コーディングエージェントの急速な進化です。 Kiro に代表されるコーディングエージェントは、自然言語の対話から要件定義・設計・実装・テストまでを支援できるまでに進化し、エンジニアでなくとも、アイデアを短時間で「動くもの」に落とし込めるようになりました。 これにより、「顧客起点で何を作るべきかを考える力（Working Backwards）」と「それを素早く形にする力（AIコーディングエージェント Kiro）」が地続きになり、アイデアの価値を構想で終わらせず、その場で動かして検証できるようになりました。昨年はアイデア創出が中心でプロトタイプ開発は任意でしたが、こうした技術の進化を背景に、今年は「考える」から「作る」までをやり切る2日間へと踏み切りました。 イベント概要 項目 内容 開催日時 2026年6月11日（木）、12日（金） 会場 AWS 麻布台オフィス（麻布台ヒルズ 森JPタワー） 参加者数 47名 参加企業 金融関連企業 13社（12チーム） AWS GenAI Catapult! とは 「AWS GenAI Catapult!」は、顧客起点での生成 AI ユースケースを創出し、世に送り出すための発射台（カタパルト）としての位置づけで、その意図をイベント名の「Catapult」に込めています。生成 AI の学習・スキル習得に留まらず、ユーザーの課題や体験に焦点を当て、Amazon 流のイノベーション文化を理解し、「Working Backwards」手法による実践的なユースケース創出につなげることを目指しています。今年はさらに、創出したユースケースを Kiro でプロトタイピングし、動くアプリケーションとして発表するところまでを2日間で体験いただきました。企業横断の交流セッション「World Café」も実施し、参加者同士の学びの共有とネットワーキングの機会も提供しました。 イベント開催報告 参加企業・チーム 金融領域の事業会社・サービサーなど 13社にご参加いただき、12チームを編成して臨みました。各社が個性豊かなチーム名で参加しています。 チーム名 会社名 Masult 株式会社アイフィスジャパン 麴町 Squad 株式会社オリエントコーポレーション TQQQ 株式会社QUICK 東池袋 4+1 株式会社クレディセゾン やる KIRO 満々 株式会社ジェーシービー しんぷれこ シンプレクス株式会社 NEXT BAMBOO 株式会社セゾンテクノロジー えぇアイをつくる会 CHEER証券株式会社 TMN Sei-katsu-sha AI Lab 株式会社トランザクション・メディア・ネットワークス AIに任せ隊 株式会社Finatext / 株式会社ナウキャスト P:AI プレミアグループ株式会社 ほか、1社 AWS GenAI Catapult! 1日目 Amazon Culture of Innovation Session / Working Backwards Experience Workshop 1日目は、Amazon のイノベーションを支えるカルチャーとテクノロジーの紹介から始まりました。Amazon は「地球上で最もお客様を大切にする企業であること」を使命とし、徹底したお客様志向、あくなき挑戦、辛抱強さを基本理念としています。お客様から逆算して考える「Working Backwards」というメカニズム、「Every day is still Day One」という心構え、小さく権限委譲された「Two-pizza チーム」という組織構造、そして変化に対応できるアーキテクチャが、イノベーションを生み出す源泉であることが説明されました。失敗を恐れず Builder 精神を持った社員が、顧客中心主義に基づいて新しい顧客体験を創造している——その文化が共有されました。 Working Backwards 体験ワークショップでは、参加者は各社チームに分かれ、生成 AI を活用したユースケースの創出に取り組みました。「Customer Obsession（お客様へのこだわり）」「Think Big（広い視野で考える）」「Bias for Action（行動へのこだわり）」というリーダーシッププリンシプルに基づき、まず「お客様は誰か」を特定し、課題を明確化。続いて課題を解決するソリューションとその目玉機能を考案し、最終的にプレスリリース形式でアイデアをまとめます。完成したプレスリリースは他チームに発表し、建設的なフィードバックを受けることで、アイデアをさらに洗練させていきました。 参加者からは「要件定義ではなく“体験定義”をするという観点が非常に勉強になった」「プレスリリースから物事を考えること自体が新鮮だった」という声が多く聞かれました。 AWS GenAI Service Introduction / AWS Dojo Hands-on [ Kiro ] 続いて、AWS Session で AWS の生成 AI サービスの全体像を学び、続くAWS Dojo Session ではいよいよ AI コーディングエージェント Kiro のハンズオンに取り組みました。AWS のワークショップ「Kiroで学ぶ：AI駆動開発」を教材に、まず講師が Vibe モード（AI と会話しながら探索的に実装を進める使い方）をデモで実演。続いて参加者自身が Spec モード（仕様駆動開発）を実践し、要件を Kiro の Spec に落とし込み、そこから自動生成される設計ドキュメントを確認しました。Vibe（素早く作る）と Spec（要件→設計→タスクに構造化する）の両方をここで体験することで、翌日のプロトタイプ開発で両者を使い分けるための確かな助走となりました。 AWS GenAI Catapult! 2日目 Prototyping Workshop with Kiro 今年最大の挑戦が、AI コーディングエージェント Kiro を用いたプロトタイプ開発です。Working Backwards で描いた顧客体験を、構想で終わらせずに「動くもの」へと変えていきます。Kiro は、次の３つの機能をうまく活用頂くことで効率良く開発を進めていくことができます。 Spec（仕様）：自然言語の対話から、要件定義・設計ドキュメント・実装タスクを構造化 Steering（制約）：Steering ファイルで規約やアーキテクチャ制約を AI に教え、チームの意図に沿った実装へ誘導 Coding（実装）：タスクリストに沿って AI が実装。必要に応じて Vibe コーディングで素早く形にする 開発をスムーズに始められるよう、運営からは Working Backwards やアプリ雛形の生成などのスキルと、規約・アーキテクチャ制約を定義したステアリングを同梱した「スターターキット」を配布しました。各チームはまず Day1 で作った PR/FAQ を Spec に落とし込み、アプリの雛形を生成。生成 AI 部分はモックと実モデルを切り替えられる構成（Mock/Real 切替）にしておくことで、ネットワークやモデルに左右されずデモのシナリオを安定させる工夫も共有されました。実装は「頼む → 動かす → 確認する → 次へ」という小さなループ（黄金ループ）を回し、迷子にならずに少しずつ完成へ近づけていきます。 「雑な自然言語からでも仕様書やモックを作成してくれる」「開発未経験でもここまで作れるのかと驚いた」「要件定義からテストまで1〜2時間で実行できた」——短時間で完成度の高い成果物が生まれていく様子と、会場のあちこちで驚きの声を聞くことができました。 参加チーム プレスリリース発表 & デモ & QA 2日目午後、いよいよ発表の時。今年は プレスリリースに加えて、Kiro で作り上げた動くプロトタイプのデモ を披露するスタイルです。12チームを4チーム×3ブロックに分けて予選を行い、各ブロックの1位が決勝に進出するトーナメント形式で実施しました。各チームが顧客課題に深く向き合い、生成 AI ならではの新しい顧客体験を提案。単なる業務効率化に留まらず、顧客体験を根本から再定義するような大胆な提案が並び、Q&A では他チームの提案を積極的に理解しようとする姿が印象的で、会場は熱気に包まれました。 AWS World Café [AI 活用推進] 生成 AI 活用をテーマにした参加者交流セッション「World Café」を開催しました。少人数グループで「ホスト」と「旅人」の役割を交代しながらメンバーの組み合わせを変え、対話を深めていく独自の形式です。結論や合意形成を目的とせず、多様な意見の共有と相互理解の深化を重視。「同じ課題に直面していることがわかって安心した」「他業種の取り組みが参考になった」など、業界や立場を超えた対話から多くの共感と気づきが生まれました。 Networking Party & Awards Ceremony *表彰式 セッション終了後、会場は和やかなネットワーキングパーティーへ。参加者は2日間の学びを共有し合い、企業の垣根を越えた新たな繋がりが次々と生まれました。表彰式では、AI審査員を加えた5名による厳正な審査の結果、以下の3チームがAWS Awardsを受賞しました。 優勝：TMN Sei-katsu-sha AI Lab ( 株式会社トランザクション・メディア・ネットワークス ) 準優勝：P:AI （ プレミアグループ株式会社） 3位：TQQQ （ 株式会社QUICK ） さらに、プレスリリースの完成度を称える特別賞「Kiro賞」を、しんぷれこ（シンプレクス株式会社）／AIに任せ隊（株式会社Finatext・株式会社ナウキャスト）／やる KIRO 満々（株式会社ジェーシービー） の3チームが受賞しました。受賞チームには記念トロフィー・メダルと AWS クレジットが贈られ、参加者全員にも AWS オリジナルグッズが配布されました。会場は受賞チームへの祝福と拍手に包まれ、和やかな雰囲気の中で締めくくられました。 参加者の声 本イベントの参加者アンケート（回答47件）では、総合満足度（CSAT） 4.8 / 5.0 と昨年（CSAT 4.6）を上回る非常に高い評価をいただきました。また、Working Backwards × 生成 AI によるサービス創出プロセスの有用性も 4.76 / 5.0、今後も Kiro を業務で使いたい と回答した方は約94%にのぼりました。参加者からは、次のような声が寄せられました。 「要件定義ではなく“体験定義”をするという観点が非常に勉強になった」 「雑な自然言語からでも仕様書やモックを作ってくれるのがすごくよい」 「開発をしたことがない人間でも、ここまで作れるのかと興奮した」 「他社の AI 活用のリアルな実情やアイデアを聞ける、貴重な交流の場だった」 「‘それは私たちの仕事ではありません、と言わない’を自分の信条にしたい」 運営の工夫 — イベント運営そのものも生成 AI と 今年は、イベントの「中身」だけでなく「運営」にも AI コーディングエージェントを活用しました。参加者に Kiro での開発を勧める私たち運営自身が、その Kiro を使って運営の仕組みを作り上げる——これもまた、今年のイベント開催における裏テーマでした。 イベントポータルサイトの開発 当日の参加者体験を一元化するため、専用の イベントポータルサイト を内製しました。参加者はこのポータルから、当日のアジェンダ・各セッションのガイド、開発チートシート、FAQ／トラブルシューティングを確認でき、完成した成果物（PR/FAQ・発表スライド・プロトタイプ・デモ動画）をカテゴリ別にアップロードできます。 技術構成はフロントエンドに React + Vite + TypeScript、バックエンドに AWS Amplify Gen2（認証は Amazon Cognito、ストレージは Amazon S3、ホスティングは Amplify Hosting）を採用。チーム単位のアカウントを運営が事前発行し、各チームの成果物は S3 上で IAM により相互に隔離（他チームからは参照不可、運営のみ横断アクセス可）しました。参加者が金融機関であることを踏まえ、全ページ認証必須・S3 のパブリックアクセス全ブロックと暗号化・成果物の一定期間後の自動失効といった、セキュリティとデータ保護の作り込みも行っています。 アプリ開発用スターターキットの準備と配布 コーディングエージェントを初めて使う参加者でも、半日で動くアプリを作り切れるように、運営が事前に「スターターキット」を配布しました。0 から作るのではなく、これを起点に開発できるようにする狙いです。 キットには、Working Backwards の PR/FAQ・ストーリーボードの生成、発表資料づくり、コーディングエージェントの「運転ガイド」、Spec / Vibe の使い分け、生成 AI アプリの雛形生成、HTML スライド作成といった用途別の スキル群 と、毎回守ってほしい制約を定義した ステアリング（共通ガードレール）、そして開発中に手元で見る 1 ページの早見表やトラブルシュートを同梱しました。これにより、初心者がつまずきやすい「曖昧に大きく頼んで迷子になる」「動作確認せずに進む」「生成 AI 連携部分を自力で組めない」「Spec を巨大にして破綻する」といった落とし穴を、あらかじめ吸収できるよう設計しています。 Kiro と AI 駆動型開発 特筆すべきは、ポータルサイトもスターターキットも、コーディングエージェント Kiro を使って開発したことです。とりわけポータルサイトは、Kiro の Spec モード（仕様駆動開発） を用い、要件定義（requirements）→ 設計（design）→ タスク分解（tasks）という流れで開発しました。これはまさに、当日参加者に体験いただいた開発プロセスそのものです。 「考える」から「作る」までを生成 AI で地続きにする——その手応えを、運営は準備段階から自ら検証していました。参加者に届けた体験は、私たち自身が有効性を確かめたうえでお渡ししたもの、と言えます。 まとめ 「AWS GenAI Catapult! 」は、単なる技術セミナーではなく、顧客起点でのイノベーション創出プロセスを学び、実践する場です。今年は Working Backwards による「考える」体験に、Kiro による「作る」体験を加え、アイデアを2日間で動くプロトタイプにまで昇華させる挑戦を行いました。生成 AI という革新的技術を真に価値あるものにするためには、技術の可能性を理解しつつ、常に顧客価値を中心に据えたアプローチが不可欠です。そして今、その顧客価値を「素早く形にして検証する」ことが、誰の手にも届く時代になりました。参加者の皆様がこの本質を体感し、自社での実践に活かしていただけることを心から願っています。 最後に、2日間にわたり熱心にご参加いただいた皆様、そして革新的なアイデアとプロトタイプを生み出してくださった各チームの皆様に、心より感謝申し上げます。皆様の挑戦が、日本の生成 AI 活用を加速し、新たな顧客価値の創造へとつながることを確信しています。AWS では今後もお客様のイノベーション創出を支援するプログラムを継続的に提供してまいります。

はじめに こんにちは、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を使った開発フローをエンジニア以外のメンバーと協働して進めるためのスキルについて紹介しました。エンジニア以外のメンバーとともに開発するチームで、 全員が安心して開発できる環境づくりの一助になれば幸いです。 「こうしたらもっと良くなる」「自分のチームではこうしてる」などがあれば、是非コメントください！