## プロンプト設計の原則
### 上流工程（要件定義・基本設計・詳細設計）向け
- 以下の要素で構成する
- **役割の指定**：どういう立場で回答させるか（例：「業務システム開発経験豊富なシステムアナリスト」）
- **背景・コンテキスト**：システムの概要・技術スタック・動作原理など前提情報
- **インプット情報**：そのフェーズで確定した成果物の内容
- **出力指示**：何をどの形式で生成させるか。以下を明示することが品質向上につながる
- 確定済み内容と叩き台として追記する内容を区別して出力するよう指示する
- 出力してほしいものだけでなく出力してほしくないものも明示する
- 出力形式（表・項目構成など）を具体的に指定する
- プロンプトは単体で完結する情報を持たせる（使用するツールがプロンプト外の文書を参照できない場合、必要な情報はプロンプト内に展開して記載する）
### 製造・テストフェーズ向け
- 以下の要素で構成する
- **前提・条件**：対象のPR番号・ブランチ・テスト方針など作業の前提となる指定を記載する
- **作業内容**：タスク固有の実装内容・指示を記載する
- **参照ファイル**：起点となるファイルを指定し、対象ファイルをAIに特定させる。タスク固有の機能・画面仕様は該当する仕様ファイル（例：docs/配下）の参照を指示する
- **証跡**：「AGENTS.mdの証跡ルールに従いPRコメントに記載すること」とする
- 一度に全部を頼まず、タスク（動作確認できる単位）で区切る
- AGENTS.mdに共通ルール・制約を記載し、タスク固有の内容はタスクプロンプトで指示する
- タスクのアウトプットを明確化する（明確な成功基準を持つタスクでDevinは力を発揮する）
- 出力してほしくないことはAGENTS.mdの「実装しないこと」に明示する
---
## 運用ルール
### AGENTS.mdの管理（Devin,Claude共通）
- 初版は「新しいエンジニアに最初に渡すオリエンテーション資料」と考えると加減がわかりやすい
- リビングドキュメントとして扱い、状況の変化や新しい知見に合わせて随時更新する
- タスク共通で判断の根拠とする情報を含める。タスク固有の情報は含めずに肥大化させない（目標値: 200行以下）
- タスク固有の機能・画面仕様はAGENTS.mdに含めず、個別ファイル（例：docs/配下）として管理し、該当タスクのプロンプトで参照を指示する（トークン節約と指示遵守率の向上につながる）
- 「実装しないこと」はAIが意図を誤解しないよう具体的に書く
- PRコメントへの証跡記載ルールをAGENTS.mdに定義する
- Claude Code用にCLAUDE.mdを作成し、冒頭に`@AGENTS.md`と記載して同じ階層上のAGENTS.mdをインポートする
### Skillsの活用（Devin,Claude共通）
- デプロイ手順、リリースチェックリスト、レビュープロセスといった、繰り返し行われる手順に関する指示は、skillとして`.claude/skills//SKILL.md`に定義する
- Claude：スラッシュコマンド（`/skill-name`）による実行やタスクへの自動マッチングを通じてClaudeがそのスキルを呼び出す
- Devin：`@skills:skill-name`による実行や関連性に基づいてDevinがスキルを自動的に呼び出す
### 決定的な保護機能（Hooks / Permissions / Managed settings）（Claude専用）
- 指示によるガードレールは従われない場合があるため、確実に守らせたいルールは指示ではなくコードによる強制（hooks/permissions/managed settings）で担保する
- **[Hooks](https://code.claude.com/docs/ja/hooks)**：`PreToolUse`イベントでツール呼び出しを検査し、終了コード2で強制ブロックする
- 適用例：特定ディレクトリ（本番設定ファイル等）への書き込み禁止、危険コマンド（DB削除系等）の実行禁止、フォーマッタ・静的解析ツールの強制実行
- **[Permissions](https://code.claude.com/docs/ja/permissions)**：ツールごとの利用可否（許可／確認／禁止）を`settings.json`に定義し、プロジェクト単位で権限範囲を制御する場合に用いる
- **[Managed settings](https://code.claude.com/docs/ja/settings)**：管理者がデプロイし、ユーザーのローカル設定で上書き不可。組織全体で一貫した強制力を持たせたいルール（秘密情報アクセス禁止、本番DB操作禁止等）はこちらで担保する
### DESIGN.mdの管理（Devin,Claude共通）
- デザインシステム（配色・タイポグラフィ・コンポーネント仕様等）を機械可読・人間可読のハイブリッド形式で一元管理する
- UI生成タスクのプロンプトからDESIGN.mdを参照させ、実装のたびに見た目がぶれないようにする
- 既存デザインがない場合は初版を「現状のUIから抽出したスタイルガイド」として作成し、以降はAGENTS.md同様リビングドキュメントとして更新する
### AGENTS.md等の構成例
- 固有ルールを適用する階層にAGENTS.mdとCLAUDE.mdをセットで配置する。
- [パス固有のルール](https://code.claude.com/docs/ja/memory#organize-rules-with-claude/rules/)は.claude/rules/にpathsスコープを指定して切り出す。
- 決定的な保護機能（hooks/permissions）は.claude/settings.jsonに、繰り返し発生する手順はskillとして.claude/skills/に定義する。
- デザインはDESIGN.mdとして、AGENTS.mdと同じ階層または対象範囲の粒度に応じてapp/frontend/等の下層に配置する。
```
project/
├── AGENTS.md # プロジェクト全体の共通ルール
├── DESIGN.md # デザインシステム（配色・タイポグラフィ・コンポーネント仕様）
├── CLAUDE.md # @AGENTS.md
├── .claude/
│ ├── settings.json # hooks・permissionsの定義（プロジェクト共有）
│ ├── rules/
│ │ └── frontend.md # パス固有ルール（Claude専用）
│ └── skills/
│ └── code-review/
│ └── SKILL.md # 繰り返し発生する手順（例：コードレビュー）
├── app/
│ ├── api/
│ │ ├── AGENTS.md # app/api/ 固有ルール（DevinもClaude Codeも参照）
│ │ └── CLAUDE.md # @AGENTS.md（→ app/api/AGENTS.mdを参照）
│ └── frontend/
│ ├── AGENTS.md # app/frontend/ 固有ルール
│ ├── CLAUDE.md # @AGENTS.md（→ app/frontend/AGENTS.mdを参照）
│ └── DESIGN.md # frontend固有のデザイン仕様
└── docs/ # 機能・画面仕様（タスクのプロンプトで参照を指示）
```
> 参考
- [How Claude remembers your project](https://code.claude.com/docs/ja/memory)
- [Steering Claude Code: CLAUDE.md files, skills, hooks, rules, subagents and more](https://claude.com/ja/blog/steering-claude-code-skills-hooks-rules-subagents-and-more)
- [Example Structure](https://docs.devin.ai/desktop/cascade/agents-md#example-structure)
- [サポートされているスキルファイルの配置場所](https://docs.devin.ai/ja/product-guides/skills#%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%82%B9%E3%82%AD%E3%83%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E9%85%8D%E7%BD%AE%E5%A0%B4%E6%89%80)
---
### Devin活用ルール
#### タスク設計
- ジュニアエンジニアが半日程度で完了できる粒度を1タスクの目安とする
- 例：環境構築・プロジェクト初期化、画面モック作成、画面単位の機能実装、テストコード生成・実行
- チームメイトに依頼する時と同じように必要なコンテキスト情報を提供する
- 例：技術スタック・DB設計・画面仕様（AGENTS.md）、対象画面・機能の仕様、参照すべきファイル
#### セッション・PR管理
- タスクごとにセッションを切り替える（セッションをまたいだ作業継続は避ける）
- PRへの修正指示は同じセッションに投入し、同じPRブランチに追加コミットさせる
- PRをcloseして再作成させるのはタスクの方向性が根本的に誤っている場合のみ
> 参考
- [デビンの置かれている環境はどのようなものですか？](https://docs.devin.ai/onboard-devin/environment#what-is-devin%E2%80%99s-environment)
---
### Claude.ai / Claude Code活用ルール
- 用途に応じて使い分ける
- 文書生成・叩き台作成（上流工程）：Claude.ai（ブラウザ版）を使用する
- コードレビュー・修正・補助（製造以降）：ターミナル版のClaude CodeまたはVS Code等IDE上からClaude Codeを使用する
- コードベースが存在しない工程ではDevinのAskモードよりClaude.ai（ブラウザ版）を優先して使用する
- DevinのPRに対する修正ではDevinに返却するよりClaude Codeを優先して使用する
> 参考
- [Claude Codeを実行する場所](https://code.claude.com/docs/en/platforms#where-to-run-claude-code)
- [クロードがアクセスできるもの](https://code.claude.com/docs/en/how-claude-code-works#what-claude-can-access)
---
### AIアウトプットのレビュー観点
#### 上流工程
- 網羅性：確定済みの方針・要件が漏れなく含まれているか
- 整合性：インプット情報・項目間で矛盾がないか
- 逸脱：対象外と決めた内容をAIが超えていないか
- 過剰補完：目的・規模に対して過剰な追記がないか
- 抽出漏れの確認：叩き台の追記内容から考慮漏れを判断し必要であれば方針を見直す
#### 製造・テストフェーズ
- 仕様準拠：画面・機能設計との整合性が取れているか
- セキュリティ：セキュリティ上の問題がないか
- 保守性：可読性・保守性に問題がないか
- 網羅性：テストケース・テストコードが仕様を網羅しているか
2026/08/02
AI導入時の運用ルール・プロンプト設計ガイドライン
2026/07/19
AI model lineup 2026
# 主要AIベンダー モデルラインナップ早見表（2026年7月時点） > 料金・スペックは変動するため、最終確認は各公式ドキュメントで行うこと。 > 価格単位はすべて USD / 100万トークン（Input / Output）。 --- ## 1. Anthropic（Claude シリーズ） **ティア構造：** Mythos > Fable > Opus > Sonnet > Haiku（上ほど高性能・高コスト） | モデル | API model ID | コンテキスト | 料金（入/出） | 特徴・用途 | |---|---|---|---|---| | **Claude Fable 5** | `claude-fable-5` | 1M tokens | $10 / $50 | 最上位Mythosクラスの一般公開版。安全分類器付き。最難タスク向け。※輸出規制で一時停止中 | | **Claude Opus 4.8** | `claude-opus-4-8` | 1M tokens | $5 / $25 | Fable停止中の実質旗艦。長時間エージェント・複雑推論・Claude Codeの主力 | | **Claude Opus 4.7** | `claude-opus-4-7` | 1M tokens | $5 / $25 | 4.8の前世代。高解像度ビジョン・自己検証機能 | | **Claude Opus 4.6** | `claude-opus-4-6` | 1M tokens | $5 / $25 | SWE-bench 80.8%。コーディング・科学推論に強い | | **Claude Sonnet 5** | `claude-sonnet-5` | 1M tokens | $3 / $15（イントロ：$2 / $10 ※〜8/31）| 速度と知性のバランス最新版。Claude Codeデフォルト候補 | | **Claude Sonnet 4.6** | `claude-sonnet-4-6` | 200K（β:1M） | $3 / $15 | コスパ安定版。本番アプリ向け | | **Claude Haiku 4.5** | `claude-haiku-4-5-20251001` | 200K | $1 / $5 | 最速・最安。高ボリューム処理・ルーティング・分類タスク | **提供形態：** - チャット：claude.ai（Free / Pro $20/月 / Max $100〜200/月 / Team / Enterprise） - API：api.anthropic.com（従量課金） - クラウド：Amazon Bedrock、Google Cloud Vertex AI、Microsoft Azure AI Foundry - 開発ツール：Claude Code（CLI）、Claude Platform on AWS **公式料金ページ：** - モデル一覧・API料金：https://www.anthropic.com/pricing - APIドキュメント（モデル一覧）：https://docs.anthropic.com/en/docs/about-claude/models/overview --- ## 2. OpenAI（GPT-5.6 / GPT-5.5 / o-series） **ファミリー構造：** GPT-5.6系（最新・3ティア）＋ GPT-5.5系（前世代現役）＋ GPT-4.1系（旧世代継続） | モデル | コンテキスト | 料金（入/出） | 特徴・用途 | |---|---|---|---| | **GPT-5.6 Sol** | 1M tokens | $5 / $30 | 最上位。難易度の高いコーディング・エージェント・研究タスク（2026/7/9 GA） | | **GPT-5.6 Terra** | 1M tokens | $2.50 / $15 | バランス本番モデル。GPT-5.4と同価格帯で新世代性能 | | **GPT-5.6 Luna** | 1M tokens | $1 / $6 | 高速・低コスト。ルーティング・チャット・高ボリューム | | **GPT-5.5** | 1M tokens | $5 / $30 | 前世代旗艦。引き続き現役 | | **GPT-5.5 Pro** | 1M tokens | $30 / $180 | 最高品質推論モード。高価値タスク限定 | | **GPT-5.4 mini** | — | $0.75 / $4.50 | コスト削減版 | | **GPT-5.4 nano** | — | $0.20 / $1.25 | 超軽量。分類・抽出・高ボリュームバックエンド | | **GPT-5.3 Codex** | — | $1.75 / $14 | コーディングエージェント特化API | | **o4-mini** | — | $0.55 / $2.20 | 推論特化・低コスト。数学・コード・論理 | | **GPT-4.1 nano** | — | $0.10 / $0.40 | 最安。GPT-3.5互換の置き換え用 | **提供形態：** - チャット：ChatGPT（Free / Plus $20/月 / Pro / Team / Enterprise） - API：platform.openai.com（従量課金、Batch API 50%オフ） - クラウド：Azure AI Foundry（Microsoft） **公式料金ページ：** - API料金：https://openai.com/api/pricing/ - モデル一覧：https://platform.openai.com/docs/models --- ## 3. Google（Gemini シリーズ） **ティア構造：** Pro（最高性能）> Flash（高コスパ）> Flash-Lite（超軽量） **世代：** Gemini 3.6（7/21最新）、3.5 / 3.1 が現役、2.5系は旧世代 | モデル | コンテキスト | 料金（入/出） | 特徴・用途 | |---|---|---|---| | **Gemini 3.6 Flash** | 1M tokens | $1.50 / $7.50 | 最新Flash。コーディングでPro並みの性能を低コストで（2026/7/21 GA） | | **Gemini 3.1 Pro** | 2M tokens | $2 / $12（≤200K）、$4 / $18（>200K） | 最強推論。GPQA Diamond 94.3%。Deep Thinkモード | | **Gemini 3.5 Flash** | 1M tokens | $0.75 / $4.50 | エージェント・コーディング向け前世代Flash | | **Gemini 3.1 Flash** | — | $0.50 / $3 | 本番アプリ・チャット・コンテンツ生成 | | **Gemini 3.1 Flash-Lite** | — | $0.25 / $1.50 | 超低レイテンシ・高ボリューム | | **Gemini 2.5 Pro** | 1M tokens | $1.25 / $10（≤200K）、$2.50 / $15（>200K） | 旧世代最上位。GA版で安定性あり | | **Gemma 4**（OSS） | 256K | 無料（セルフホスト） | Apache 2.0。31B dense / 26B MoE | **提供形態：** - チャット：Gemini app（AI Plus $4.99/月 / AI Pro $19.99/月 / AI Ultra $99.99〜199.99/月） - API：Google AI Studio（開発用・無料枠あり）、Vertex AI（エンタープライズ、2026/7〜リージョナル+10%） - 開発：Gemini CLI、Google Antigravity（エージェントプラットフォーム） **公式料金ページ：** - Gemini API（Google AI Studio）：https://ai.google.dev/gemini-api/docs/pricing - Vertex AI（エンタープライズ）：https://cloud.google.com/vertex-ai/generative-ai/pricing --- ## 4. Meta（Llama 4 / Muse Spark） **方針転換：** オープン路線を継続しつつ、初のクローズドモデル（Muse Spark）も投入 | モデル | 形態 | コンテキスト | 特徴・用途 | |---|---|---|---| | **Muse Spark** | クローズド（API） | — | Meta初の独自フロンティアモデル。ツール使用・マルチエージェント | | **Llama 4 Maverick** | オープンウェイト | 1M tokens | 400B total / 17B active MoE。マルチモーダル。本番汎用 | | **Llama 4 Scout** | オープンウェイト | 10M tokens | 109B total / 17B active。超長コンテキストRAG。H100×1台で動作 | **ライセンス：** Llama 4 Community License（商用可、MAU 7億超は要許可） **提供形態：** Meta AI（チャット）、Hugging Face（ウェイト配布）、主要クラウド経由 **備考：** Llama 4 Behemoth（~2T params）は事実上凍結。 **公式ページ：** - Llama モデル：https://ai.meta.com/models/ - Hugging Face（ウェイト配布）：https://huggingface.co/meta-llama - ※ Llama 自体に直接API料金はなし（ホスティングはGroq / Together AI / AWS等経由） --- ## 5. DeepSeek（中国・オープン系最有力） **特徴：** MITライセンス・超低価格・コーディング・推論に強い。API はOpenAI互換 **重要：** 旧エイリアス `deepseek-chat` / `deepseek-reasoner` は2026/7/24に廃止 | モデル | 形態 | コンテキスト | 料金（入/出）※キャッシュミス | 特徴・用途 | |---|---|---|---|---| | **DeepSeek V4-Pro** | OSS（MIT） | 1M tokens | $0.435 / $0.87 | 1.6T total / 49B active MoE。フラッグシップ。コーディング・推論・エージェント | | **DeepSeek V4-Flash** | OSS（MIT） | 1M tokens | $0.14 / $0.28 | 284B total。高ボリューム・分類・抽出向けコスト重視 | > キャッシュヒット時は入力コスト約50〜100分の1（V4-Flash: $0.0028/M、V4-Pro: $0.003625/M） **提供形態：** DeepSeek API（OpenAI互換）、Hugging Face（ウェイト）、各クラウド経由 **公式料金ページ：** - API料金：https://api-docs.deepseek.com/quick_start/pricing - モデル情報：https://api-docs.deepseek.com/ --- ## 6. Mistral AI（欧州） **特徴：** EU法規制対応・データ主権・多言語。一部モデルは真のオープンソース | モデル | 形態 | コンテキスト | 料金（入/出） | 特徴・用途 | |---|---|---|---|---| | **Mistral Large 3** | オープンウェイト（Apache 2.0） | 256K | $0.50 / $1.50 | 675B total / 41B active MoE。多言語200言語以上 | | **Mistral Medium 3.5** | API / 一部ウェイト | — | 参照要 | コスパバランス。2026年4月リリース | | **Mistral Small 4** | オープンウェイト | — | $0.10 / $0.30 | 軽量・高速。2026年3月リリース | | **Voxtral TTS** | API | — | 参照要 | 音声生成・ゼロショット音声クローン | **提供形態：** La Plateforme API、Azure / GCP / AWS 経由 **公式料金ページ：** - API料金・モデル一覧：https://mistral.ai/technology/ - La Plateforme コンソール：https://console.mistral.ai/ --- ## 7. Alibaba（Qwen シリーズ） **特徴：** Apache 2.0・多言語・グローバルOSSシェア50%超。コーディング強い | モデル | 形態 | コンテキスト | 特徴・用途 | |---|---|---|---| | **Qwen 3.5（397B A17B）** | OSS（Apache 2.0） | 262K（拡張1M+） | GPQA Diamond 88.4%。マルチモーダル・多言語200言語 | | **Qwen 3.6 27B** | OSS（Apache 2.0） | — | SWE-bench 77.2%。コーディング特化。単一H100で動作 | | **Qwen 3.7 Max** | クローズド（DashScope API） | — | Alibaba製クラウドAPIのみ提供 | **提供形態：** Alibaba Cloud DashScope API、Hugging Face（ウェイト） **公式料金ページ：** - DashScope API料金：https://www.alibabacloud.com/help/en/model-studio/getting-started/models - Hugging Face（ウェイト）：https://huggingface.co/Qwen --- ## ベンダー横断まとめ：選択指針 | 優先軸 | 推奨モデル | |---|---| | 最高性能（コスト度外視） | Claude Opus 4.8（Fable停止中）/ GPT-5.6 Sol / Gemini 3.1 Pro | | コスパ最良の本番バランス | Claude Sonnet 5 / GPT-5.6 Terra / Gemini 3.6 Flash | | 超低コスト・大量処理 | Claude Haiku 4.5 / GPT-4.1 nano / Gemini 3.1 Flash-Lite | | コーディング・エージェント | Claude Opus 4.8（Claude Code）/ DeepSeek V4-Pro | | 推論・数学 | DeepSeek V4-Pro / o4-mini / Gemini 3.1 Pro Deep Think | | セルフホスト・データ主権 | DeepSeek V4 / Qwen 3.5 / Llama 4 Maverick / Gemma 4 | | EU法規制・欧州データ | Mistral Large 3 | | 超長コンテキストRAG | Llama 4 Scout（10M tokens） | | 最安フロンティア | DeepSeek V4-Pro（$0.435/$0.87、西側旗艦比10〜35倍安） | --- ## 参考：ベンダー横断の料金比較サービス | サービス | URL | 特徴 | |---|---|---| | AI Pricing Guru | https://www.aipricing.guru/pricing/ | 11プロバイダー・112モデルを毎日更新 | | Price Per Token | https://pricepertoken.com/ | 300+モデルを横断比較。コスト計算機付き | | BenchLM | https://benchlm.ai/ | ベンチマーク+料金の総合比較 | | DevTk.AI | https://devtk.ai/en/blog/ai-api-pricing-comparison-2026/ | 50+モデルの詳細な比較記事 |
2026/06/18
Gitリポジトリの操作
Gitでは変更の保存先が4つの場所に分かれており、コマンドによってどの場所まで変更を反映するかが決まる。 `add` → `commit` → `push` と段階を踏むのが基本で、`commit -a` や `pull` は複数の操作をひとつのコマンドにまとめた省略形にあたる。 --- ## 4つの場所 | 場所 | 別名 | 物理的な位置 | 役割 | |------|------|-------------|------| | Workspace | 作業ディレクトリ | 自PC（.git/ の外） | 実際にファイルを編集する場所 | | Index | ステージングエリア | 自PC（.git/ 内） | 次のコミットに含める変更を仮置きする場所 | | Local repo | ローカルリポジトリ | 自PC（.git/ 内） | コミット履歴・ブランチの保管場所 | | Remote repo | リモートリポジトリ | 外部サーバー | GitHub / GitLab など、チームで共有する場所 | --- ## ブランチの実体 すべてのブランチは `.git/` フォルダ内に格納されている。Workspaceに見えているファイルは「現在チェックアウトしているブランチの中身」だけ。 ``` repo/ ├── .git/ │ ├── refs/ │ │ ├── heads/ ← ローカルブランチの参照 │ │ │ ├── main │ │ │ └── branch-xxx │ │ └── remotes/ │ │ └── origin/ ← リモートブランチの参照 │ │ ├── main │ │ └── branch-xxx │ └── objects/ ← 全ブランチのファイルの中身が圧縮されて格納 ├── app/ ├── resources/ └── ... ← 現在のブランチの中身だけが見えている ``` ブランチを切り替えると、`.git/objects/` から該当ブランチのファイルが展開されWorkspaceが書き換わる。 --- ## 送信系コマンド（ローカル → リモート方向） ### `git add`：Workspace → Index ```bash git add <ファイル> # 指定ファイルをステージ git add . # 全変更をステージ ``` ### `git commit`：Index → Local repo ```bash git commit -m "メッセージ" ``` ### `git commit -a`：Workspace → Local repo（add + commit を一括） ```bash git commit -a -m "メッセージ" ``` 追跡済みファイル（tracked）の `add` と `commit` を一括で実行する省略形。 新規ファイル（untracked）は自動でステージされないため、別途 `git add` が必要。 ### `git push`：Local repo → Remote repo ```bash git push origin main git push -u origin main # 初回。-u で upstream を設定し、以後は git push だけで OK ``` --- ## 取得系コマンド（リモート → ローカル方向） ### `git fetch`：Remote repo → Local repo ```bash git fetch origin ``` リモートの更新を Local repo に取り込むだけ。Workspace は変化しない。 取得後に `git log origin/main` で差分を確認してから merge できる。 ### `git pull`：Remote repo → Workspace（fetch + merge を一括） ```bash git pull origin main ``` `fetch` に続いて merge まで一括で行い、Workspace まで反映する。 コンフリクトが起きる可能性があるため、`fetch` → 確認 → `merge` の順が安全。 ### `git checkout` / `git switch`：Local repo → Workspace ```bash git checkout <ブランチ名> # ブランチを切り替えてワーキングツリーを更新 git switch <ブランチ名> # 現代的な書き方（checkout の代替） ``` ### `git restore`：Local repo → Workspace または Index ```bash git restore <ファイル> # Workspace の変更を最終コミット時点に戻す git restore --staged <ファイル> # Index の変更を取り消す（Workspace は変化しない） ``` ### `git clone`：Remote repo → Workspace（初回のみ） ```bash git clone``` `init` + `fetch` + `checkout` を一括実行し、リポジトリ全体をローカルにコピーする。 --- ## 比較系コマンド（差分確認） | コマンド | 比較する場所 | 確認できること | |----------|-------------|----------------| | `git status` | Workspace ↔ Index ↔ Local repo(HEAD) | 3箇所を横断し、Untracked / 未add(Modified) / Staged(add済み未commit)をまとめて一覧表示 | | `git diff` | Workspace ↔ Index | `add` 前の変更（まだステージしていない差分） | | `git diff HEAD` | Workspace ↔ Local repo | 最終コミットから現在までの全差分 | | `git diff --staged` | Index ↔ Local repo | `add` 済みでまだ `commit` していない差分 | --- ## リポジトリの作成 ### `git init`：空のローカルリポジトリを新規作成する 手元にあるフォルダをGit管理下に置く。Remote repo なしのローカル完結でも運用でき、後から `git remote add` でリモートに接続することもできる。 ```bash mkdir my-project && cd my-project git init git add . git commit -m "first commit" # ローカル完結の場合はここまで。以降は add → commit を繰り返す。 # Remote repo に接続する場合は GitHub で空リポジトリを作成してから実行 git remote add origin https://github.com/user/repo.git git push -u origin main ``` ### `git clone`：リモートリポジトリをローカルに取得する GitHub 側でリポジトリを先に作り、手元に持ってくる場合。`init` + `fetch` + `checkout` を一括で行う。 ```bash git clone https://github.com/user/repo.git cd repo ``` --- ## ブランチ切り替えとフォルダの関係 ブランチを切り替えても**フォルダ自体は変わらない**。Gitがフォルダ内のファイルをブランチに合わせて自動的に書き換える。 ``` repo/ ← フォルダは変わらない ├── app/ ├── resources/ └── ... ← 中身（ファイルの内容）がブランチに合わせて切り替わる ``` ### `gh pr checkout`：Remote repo → Workspace（PRブランチへの切り替え） 内部的に `git fetch` + `git checkout` の2ステップが走る複合操作。cloneしたリポジトリのフォルダ内で実行する必要がある（空フォルダでは実行不可）。 ```bash cd repo/ # cloneしたフォルダへ移動（mainブランチ） gh pr checkout 2 # PR #2のブランチに切り替わる git checkout main # 作業完了後、mainブランチに戻す git branch # 現在のブランチを確認（*が付く） ``` --- ### `git remote add`：既存のローカルリポジトリをリモートに接続する `git init` 済みのプロジェクトを後から GitHub に紐づける場合。 ```bash git remote add origin https://github.com/user/repo.git git branch -M main git push -u origin main ```
2026/06/12
Docker Compose と Composer を忘れない
# Docker Compose と Composer の違い | | Docker Compose | Composer | |---|---|---| | 役割 | 複数の**コンテナ**を管理するツール | PHPの**パッケージ（ライブラリ）**を管理するツール | | 対象 | コンテナ・インフラ | PHPのコードレベルの依存関係 | | 設定ファイル | `docker-compose.yml` | `composer.json` | | コマンド例 | `docker compose up` | `composer install` | | 実行場所 | ホスト側（EC2上） | コンテナ内（PHPが動く環境） | | 用途 | 「アプリを動かす箱（コンテナ群）を準備する」 | 「アプリの中で使う部品（ライブラリ）を揃える」 | ## イメージ図
# `vendor/`ディレクトリとComposerの関係 ## `vendor/`とは **Composerでインストールした全PHPパッケージの格納場所**。Laravel固有のものではなく、Composerを使うPHPプロジェクト共通の仕組み。 ``` vendor/ ├── laravel/ │ └── framework/ ← Laravel本体もここにある（1パッケージとして） ├── symfony/ ← Laravelが内部で使うコンポーネント ├── monolog/ ← ログ出力ライブラリ ├── autoload.php ← 自動読み込みの起点ファイル └── composer/ ``` 「**Laravel = vendor/の中の1パッケージ**」という位置付け。Laravelを使わないPHPプロジェクトでもComposerを使えば`vendor/`は作られる。 --- ## 各ファイル・コマンドの役割 | 要素 | 役割 | |---|---| | `composer.json` | 「何を使うか」のリスト（依存パッケージの定義） | | `composer.lock` | 「実際にインストールされたバージョン」の記録 | | `composer install` | `composer.json`/`composer.lock`に基づき`vendor/`を生成 | | `composer require` | 新しいパッケージを追加して`composer.json`に記録＋インストール | | `vendor/` | 上記に基づいてダウンロードされた全パッケージの実体 | --- `vendor/`は基本的に**Gitにコミットしない**（`.gitignore`対象）。サイズが大きく、`composer.json`/`composer.lock`があれば誰でも再現できるため。
2026/06/11
2026/06/08
SNI（Server Name Indication）
SNIは、SSL/TLSの拡張仕様の一つ。証明書の種類ではない。 | 項目 | SNI | ワイルドカード証明書 | SAN（マルチドメイン）証明書 | | :--- | :--- | :--- | :--- | | 対象（レイヤー） | 通信の仕組み・機能（TLSプロトコルの拡張） | 証明書そのものの種類（特殊な名前の書き方） | 証明書そのものの種類（複数名前を書ける仕組み） | | 実現方法 | サーバー（ALB）に、**別々の証明書を複数枚**登録し、アクセスに応じて切り替える。 | **1枚の証明書**に `*.example.com` と書き、サブドメイン全てで使い回す。 | **1枚の証明書**の「SAN欄」に、異なるドメインを複数箇条書きする。 | | ドメインの制限 | どんなドメインの組み合わせでもOK（例：`a.com` と `b.net`） | 同一ドメインのサブドメインのみ（例：`abc.com` の配下のみ） | 異なるドメインでもOKだが、上限数（ACMなら100個など）がある。 |
2026/06/07
S3の使い分け
# モック画面提供のシーン
提供方法は以下の2パターン考えられる。
---
## ① S3静的ウェブサイト（閲覧型）
### ■ 概要
- S3にHTMLファイル一式を配置
- 静的ウェブサイトホスティングを有効化
- ブラウザから直接アクセスして閲覧
---
### ■ アクセス制御
- バケットポリシーによるIP制限を実施
（例）
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificIPOnly",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "xxx.xxx.xxx.xxx/32"
}
}
}
]
}
```
---
### ■ 特徴
- S3のみで構成可能（最小構成）
- HTML間リンクがそのまま動作する
- ユーザーが画面遷移しながら確認できる
- 開発ベンダーは通常のファイルアップロードで運用可能
---
### ■ 向いている用途
- モックを「画面として操作・閲覧」させたい場合
---
### ■ 注意点
- アクセス元IPが固定されている必要がある
- ID／パスワードによる認証は行わない
---
## ② S3 + 署名付きURL（ZIP配布型）
### ■ 概要
- モック一式をZIPファイルにまとめる
- S3にアップロードする
- 署名付きURLを発行し顧客へ共有する
---
### ■ 特徴
- S3のみで構成可能（最小構成）
- URLに有効期限を設定可能
- 限定的なアクセス制御が容易
- URL共有のみで利用可能
---
### ■ 向いている用途
- モックを成果物として配布・ダウンロードさせる場合
---
### ■ 注意点
- ダウンロードおよびローカル展開が必要
- Web上での操作性はない
- 更新時は再ZIP化および再配布が必要
---
## ■ 比較
| 観点 | ① S3静的サイト | ② ZIP + 署名URL |
|------|----------------|----------------|
| 利用形態 | Web閲覧 | ダウンロード |
| 構成 | S3のみ | S3のみ |
| アクセス制御 | IP制限 | 有効期限付きURL |
| ユーザー体験 | 良い | やや制限あり |
| 更新容易性 | 高い | 低い |
---
## ■ 使い分け方針
- 日常的なレビュー用途
→ ① S3静的ウェブサイト
- 成果物としての提供・保管用途
→ ② ZIP + 署名付きURL
登録:
投稿 (Atom)