🤖

AI駆動開発の効率85%UP！GitHubドキュメント管理の7つの必須テクニック

2025/08/12に公開

AI 駆動開発の効率 85%UP！GitHub ドキュメント管理の 7 つの必須テクニック

🍵 閑話休題：ちょっと一息

本題に入る前に...最近「ダンダダン」観ました？

アニメの「お祓いだー！」のシーンが超絶ウケました😂 世代的にドンピシャだったんですかね...あの独特のテンポ感がクセになります。
※笑った人は同年代！！？

AIとドキュメント管理の話も大事ですが、たまにはアニメでリフレッシュも必要ですよね。開発に疲れたら、ダンダダンでも観て笑ってください。意外とクリエイティブな発想が生まれるかも？

さて、気を取り直して本題へ！

🎯 3 分でわかる：この記事の価値

⏰ 読了時間: 約 10 分
🎯 対象読者: Claude Code、Cursor、GitHub Copilot ユーザー
📊 実証データ: 実際のプロジェクトで 85%の効率化を達成
💡 実装難易度: ★★☆☆☆（基本的な Git 知識があれば実践可能）

😩 あなたもこんな経験ありませんか？

AI ツールに同じ説明を何度も繰り返している
チームメンバーごとに AI への指示が異なり、コードの一貫性がない
ドキュメントが古くなり、AI が誤った情報を参照してしまう
新しい AI ツールに移行するたびに設定をやり直している

これらの問題、GitHub でのドキュメント管理で全て解決できます！

📊 実測データ：Before/After

指標	Before	After	改善率
AI 指示の繰り返し回数	20 回/日	3 回/日	85%削減
新メンバーのオンボーディング	2 週間	3 日	78%短縮
ドキュメント更新頻度	月 1 回	毎コミット	自動化
AI ツール切り替えコスト	40 時間	0 時間	100%削減

なぜ GitHub にドキュメントを置くべきなのか？

AI 駆動開発において、ドキュメントを GitHub リポジトリに配置することは単なるベストプラクティスではなく、必須要件となっています。2025 年現在、Claude Code、Cursor、GitHub Copilot など主要な AI 開発ツールは、GitHub リポジトリの Markdown ファイルを参照し、コンテキストとして活用できます※1。

📊 従来の問題 vs GitHub管理による解決

以下、実践で証明された 7 つの必須テクニックを解説します。

1. 🤖 AI がリポジトリ全体を理解できる - DDD と相性抜群

ドメイン駆動設計（DDD）と AI 開発の組み合わせは最強です。Claude Code や GitHub Copilot は、GitHub リポジトリ内の Markdown ファイルを自動的に読み込み、以下を理解します：

DDD の核心要素を AI が学習

docs/
├── DOMAIN.md # ドメインモデルの説明
├── GLOSSARY.md # ユビキタス言語の定義
├── BOUNDED_CONTEXT.md # 境界づけられたコンテキスト
└── AGGREGATE.md # 集約の設計ルール

実例：AI がドメイン知識を理解する仕組み

# GLOSSARY.md

## Order（注文）

- ビジネス定義：顧客が商品を購入する取引単位
- 不変条件：注文は必ず 1 人の顧客に紐づく
- 状態遷移：pending → confirmed → shipped → delivered
- 集約ルート：OrderAggregate

AI はこの定義を読み込み、以下のような適切なコードを生成：

// AIが自動生成するDDDに準拠したコード
class OrderAggregate {
  private constructor(
    private readonly customerId: CustomerId,
    private readonly items: OrderItem[],
    private status: OrderStatus
  ) {
    // GLOSSARY.mdの不変条件を守る
    if (!customerId) {
      throw new Error("注文は必ず顧客に紐づく必要があります");
    }
  }

  // 状態遷移ルールも理解して実装
  confirm(): void {
    if (this.status !== OrderStatus.PENDING) {
      throw new Error("確認できるのはpending状態の注文のみです");
    }
    this.status = OrderStatus.CONFIRMED;
  }
}

重要: ローカルファイルや Google ドライブ、Notion 等の外部ドキュメントは AI が参照できません。GitHub リポジトリ内に配置することが必須です。

🔄 AIとドキュメントの連携フロー

2. 📝 バージョン管理でドキュメントとコードの同期が保たれる

「ドキュメントの更新が大変」という悩みは過去のものです。GitHub でドキュメントを管理すれば、AI がドキュメント更新も自動化してくれます。

よくある問題：ドキュメントが陳腐化する

❌ 従来の問題
1. コードを変更
2. ドキュメント更新を忘れる
3. ドキュメントとコードが乖離
4. 新メンバーが混乱

AI 駆動の解決策：自動同期の実現

✅ AIによる自動化
1. コードを変更
2. AIに「このコード変更に伴いドキュメント更新が必要な箇所を教えて」
3. AIが影響範囲を分析
4. ドキュメントも同時に更新
5. 1つのPRでコードとドキュメントを同期

実例：API エンドポイント追加時の自動更新

// 新しいエンドポイントを追加
router.post("/api/orders/:id/cancel", cancelOrder);

AI への指示：

このエンドポイント追加に伴い、以下のドキュメントを更新してください：
1. docs/API.md にエンドポイント仕様を追加
2. GLOSSARY.md の Order セクションに「キャンセル」状態を追加
3. README.md のAPI一覧を更新

AI が自動生成する更新内容：

# docs/API.md への追加

## POST /api/orders/:id/cancel

注文をキャンセルします。

### リクエスト

- パラメータ: `id` - 注文 ID
- ボディ:
  ```json
  {
    "reason": "キャンセル理由",
    "refund": true
  }
  ```

レスポンス

200: キャンセル成功
400: キャンセル不可能な状態
404: 注文が見つからない


#### コミット時の自動チェック

```bash
# git hookで自動チェック
git commit -m "feat: 注文キャンセル機能を追加"

# AIが自動で確認
> ドキュメント更新の必要性を検出しました：
> - docs/API.md: 新しいエンドポイントの記載が必要
> - CHANGELOG.md: 新機能の記載が必要
>
> 自動で更新しますか？ [Y/n]

重要なポイント：

コードとドキュメントが同一コミットで管理される
変更履歴が完全に追跡できる
ロールバック時もドキュメントが連動
AI が常に最新のドキュメントを参照してコード生成

3. 📋 **専用の AI 指示書を設置できる（CLAUDE.md、AGENTS.md、.cursor/*.mdc）**

各 AI ツールに対応した専用の指示書をプロジェクトルートに配置することで、チーム全体で一貫した AI 活用が可能になります。

主要な AI 指示書ファイル

ファイル名	対応ツール	用途
`CLAUDE.md`	Claude Code	プロジェクト固有の指示、ルール、コンテキスト
`AGENTS.md`	複数の AI エージェント	エージェント間の役割分担、協調ルール
`.cursor/*.mdc`	Cursor	Cursor 専用のルールファイル群（MDC 形式）
`.github/copilot-instructions.md`	GitHub Copilot	Copilot 用のカスタム指示

実例：CLAUDE.md の構成

# CLAUDE.md

## 🎯 プロジェクト概要

TypeScript で構築されたマイクロサービスアーキテクチャ

## 📚 必ず参照するドキュメント

- docs/GLOSSARY.md - 用語定義と命名規則
- docs/ARCHITECTURE.md - システム設計

## 🚫 絶対的なルール

- any 型の使用禁止
- console.log は削除（debugger を使用）
- 日本語コメントで記述

## 📝 コード生成時の優先事項

1. 型安全性を最優先
2. 単体テストを必ず作成
3. エラーハンドリングを明示的に

## 🔧 技術的制約

- Node.js: v20.x
- TypeScript: strict mode
- データベース: PostgreSQL only

AGENTS.md でエージェント間の協調を定義

# AGENTS.md

## エージェントの役割分担

### 🏗️ アーキテクトエージェント

- 責任: システム設計、技術選定
- 入力: ビジネス要件
- 出力: 技術仕様書、アーキテクチャ図

### 💻 実装エージェント

- 責任: コード実装
- 入力: 技術仕様書
- 出力: プロダクションコード、テストコード

### 🔍 レビューエージェント

- 責任: コードレビュー、品質保証
- 入力: 実装されたコード
- 出力: 改善提案、承認/却下

## 協調フロー

1. アーキテクト → 設計書作成
2. 実装 → コード生成
3. レビュー → 品質チェック
4. 承認後マージ

.cursor/*.mdc で Cursor 固有の設定

Cursor では.cursor/ディレクトリ直下に MDC 形式でルールファイルを配置します。

# .cursor/code-style.mdc

---

type: "Always"
description: "Code style rules for TypeScript"

---

## TypeScript Code Style

- Use arrow functions for all functions
- Prefer const over let
- Use template literals for string concatenation
- Strict mode must be enabled

# .cursor/testing.mdc

---

type: "Auto Attached"
description: "Automatic test generation rules"

---

## Testing Requirements

- Generate test cases for all new functions
- Use Jest for unit tests
- Aim for 80% code coverage minimum
- Include edge cases and error scenarios

# .cursor/japanese-context.mdc

---

type: "Always"
description: "Japanese language support"

---

## Japanese Language Context

- Always explain changes in Japanese
- Use Japanese comments in code
- Technical terms can remain in English
- Error messages should be bilingual

チーム全体でのメリット

一貫性の確保: 全員が同じルールで AI を活用
オンボーディングの簡素化: 新メンバーもすぐに AI を活用可能
品質の標準化: AI が生成するコードの品質を統一
ツール切り替えの容易さ: 複数の AI ツールを併用可能

4. 📚 ユビキタス言語（用語集）を AI が学習する

docs/GLOSSARY.mdに用語定義を置くことで、AI がプロジェクト固有の専門用語や命名規則を理解し、適切なコードを生成します。これが「よしなに対応してくれる」を実現するための第一歩です。

「よしなに」を実現する仕組み

前回記事「Claude Code で開発効率 85%UP！」で紹介した「AI がよしなに理解してくれる」は、実は GLOSSARY.md による用語定義が鍵です。

# docs/GLOSSARY.md

## User（ユーザー）

⚠️ 使用禁止 → 代わりに Customer を使用

## Customer（顧客）

- 定義：サービスを利用する個人・法人
- DB: customers テーブル
- API: /api/customers/\*
- 命名規則：customer で始まる変数名

## 似た概念の使い分け

- User ❌ → Customer ✅
- Buy ❌ → Purchase ✅
- Delete ❌ → Archive ✅（論理削除）

AI への指示：用語集の自動更新

新しいエンティティやAPIを追加したら、
必ずGLOSSARY.mdも更新してください。
以下の形式で記載：
1. ビジネス定義
2. 技術的な実装
3. 命名規則
4. 関連する概念

実例：AI が「よしなに」理解する様子

ユーザーの曖昧な指示：

「ユーザー削除機能を追加して」

AI の理解と実装：

// GLOSSARY.mdから理解した内容を反映
class CustomerService {
  // ❌ deleteUser ではなく
  // ✅ archiveCustomer を実装（論理削除）
  async archiveCustomer(customerId: string): Promise<void> {
    // GLOSSARY.mdの定義に従い論理削除
    await this.db.customers.update({
      where: { id: customerId },
      data: {
        archived: true,
        archivedAt: new Date(),
      },
    });
  }
}

用語集の継続的なメンテナンス

# コミット時のAIチェック
git commit -m "feat: 新規エンティティ追加"

# AIが自動確認
> 新しいエンティティ "Subscription" を検出
> GLOSSARY.mdへの追加が必要です
>
> 以下を追加しますか？
> - ビジネス定義
> - 関連テーブル
> - API エンドポイント
> [Y/n]

重要なポイント：

AI が常に最新の用語定義を参照
曖昧な指示も正しく解釈
チーム全体で用語が統一
新人でも即戦力化

5. 👥 Pull Request でドキュメントもレビューできる

ドキュメントの変更も PR レビューの対象となり、チームメンバーが内容を確認・改善できます。AI への指示も継続的に最適化されます。

なぜドキュメントレビューが重要なのか

❌ 従来の問題
- ドキュメントは個人が勝手に更新
- 間違った情報が放置される
- AIが誤った指示で動作する
- チーム内で認識のズレが発生

✅ PRレビューによる解決
- ドキュメント変更も必ずレビュー
- 複数人で内容の正確性を確認
- AI指示の最適化を全員で改善
- 知識の共有と蓄積

実例：CLAUDE.md 更新の PR レビュー

# Pull Request: CLAUDE.mdに新ルールを追加

## 変更内容
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -10,6 +10,8 @@
 ## コーディングルール
 - 関数はアロー関数で統一
 - 変数名はcamelCase
+- エラーメッセージは日本語
+- テストファイルは*.test.tsで統一

## AIへの指示
 - コメントは日本語で記述
+- エラーハンドリングは必須
+- 単体テストも同時に生成

チームメンバーからのレビューコメント

## レビューコメント例

@reviewer1:
「エラーメッセージは日本語」について、
API のエラーレスポンスは英語の方が良いのでは？
フロントエンドのみ日本語にしましょう。

@reviewer2:
テストファイルの命名規則、既存コードは
\*.spec.ts も混在してます。統一するなら
既存ファイルのリネームも PR に含めてください。

@author:
ご指摘ありがとうございます！

- API エラーは英語、UI は日本語に修正
- 既存の\*.spec.ts ファイルもリネーム対応

AI 指示の継続的改善プロセス

# .github/workflows/doc-review.yml
name: Documentation Review Check

on:
  pull_request:
    paths:
      - "CLAUDE.md"
      - "docs/GLOSSARY.md"
      - ".cursor/*.mdc"

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: AI指示の構文チェック
        run: |
          # Markdownの構文チェック
          # 用語の一貫性チェック
          # 禁止用語の検出

      - name: レビュー必須化
        run: |
          # 2人以上の承認が必要
          # ドキュメント変更は必ずレビュー

ドキュメント変更の影響分析

# AIによる影響分析
$ git diff CLAUDE.md | ai analyze-impact

影響を受けるファイル:
- src/**/*.ts (新しいコーディングルール)
- tests/**/*.spec.ts → *.test.ts (リネーム必要)
- src/utils/errors.ts (エラーメッセージの言語)

推奨アクション:
1. 既存コードの自動修正を実行
2. テストファイルの一括リネーム
3. CI/CDの設定更新

メリット：知識の民主化

透明性の確保
- 全員がドキュメント変更を把握
- AI への指示内容が明確化
品質向上
- 複数人の知見で改善
- ベストプラクティスの共有
オンボーディング効率化
- 過去の PR から学習可能
- なぜその指示になったか履歴で確認
AI の進化
- フィードバックループの確立
- 継続的な指示の最適化

6. 💻 IDE/エディタから直接参照・編集可能

VS Code や Cursor などのエディタで、コードと同じようにドキュメントを編集でき、AI もリアルタイムで更新内容を認識します。

統合開発環境でのシームレスな体験

✅ GitHubリポジトリ内のMarkdown
- エディタで即座に開ける
- コード補完が効く
- プレビュー表示可能
- AIが自動で読み込み

❌ 外部ドキュメント（Notion、Confluence等）
- ブラウザで別途開く必要
- コンテキストスイッチが発生
- AIがアクセスできない
- 更新の同期が面倒

VS Code/Cursor での活用例

1. サイドバーでドキュメント常時表示

プロジェクト構造:
├── src/
│   ├── components/
│   └── services/
├── docs/
│   ├── GLOSSARY.md     ← サイドバーに固定
│   └── API.md          ← 分割ビューで表示
├── CLAUDE.md           ← 常に参照可能
└── README.md

2. コマンドパレットから即座にアクセス

# VS Code/Cursor のコマンドパレット (Cmd+Shift+P)
> Open GLOSSARY.md
> Open CLAUDE.md
> Search in Documentation

3. AI との対話中にリアルタイム参照

// コード編集中
class CustomerService {
  // Cmd+クリックでGLOSSARY.md#Customerへジャンプ
  async createCustomer(data: CustomerData) {
    // AIが自動でGLOSSARY.mdを参照して補完
  }
}

Markdown 拡張機能との連携

// .vscode/extensions.json
{
  "recommendations": [
    "yzhang.markdown-all-in-one", // Markdown編集支援
    "bierner.markdown-mermaid", // 図表サポート
    "davidanson.vscode-markdownlint", // 構文チェック
    "ms-vscode.references-view" // 参照関係表示
  ]
}

AI アシスタントのリアルタイム認識

Claude Code/Cursor の動作

前提: プロジェクトが GitHub リポジトリとして管理され、エディタで開いている必要があります。

# ユーザーが GLOSSARY.md を編集

## Product（商品）

- 旧定義：販売する物品

* 新定義：販売する物品・サービス

# AI が即座に認識（リポジトリ内のファイルのため）

"Product の定義が更新されました。
今後はサービスも含めた実装を行います。"

重要:

✅ GitHub リポジトリ内の Markdown → AI が自動で読み込み
❌ ローカルのみのファイル → git add するまで AI は認識しない
❌ 外部サービス（Notion 等） → AI はアクセス不可

GitHub Copilot のインライン提案

// GLOSSARY.mdの更新後、即座に反映
function createProduct(
  // GitHub Copilotが新定義に基づいて提案
  type: "physical" | "service", // <- 自動提案
  name: string,
  price: number
) {
  // 実装...
}

ドキュメント駆動開発のワークフロー

便利なショートカット設定

// .vscode/keybindings.json
[
  {
    "key": "cmd+shift+g",
    "command": "workbench.action.quickOpen",
    "args": "docs/GLOSSARY.md"
  },
  {
    "key": "cmd+shift+c",
    "command": "workbench.action.quickOpen",
    "args": "CLAUDE.md"
  }
]

メリット：

コンテキストスイッチなし - エディタ内で完結
AI の即座な反応 - 保存と同時に認識
チーム全体の効率化 - 同じ環境で作業
ドキュメントの鮮度維持 - 編集の心理的ハードルが低い

7. 🔄 他の AI ツールとの互換性が高い

GitHub Copilot、Cursor、Claude Code など、主要な AI 開発ツールはすべて GitHub の Markdown を理解するため、ツールを変更しても知識資産が活用できます。

ベンダーロックインからの解放

❌ 独自形式の問題
- ツールA専用の設定ファイル
- ツールBに移行時、設定を作り直し
- 知識資産が無駄になる
- チーム内で異なるツール使用不可

✅ GitHub Markdown の利点
- 全AIツールが理解可能
- ツール切り替えがシームレス
- 知識資産を永続的に活用
- チームメンバーが好きなツールを選択

主要 AI ツールの対応状況

AI ツール	CLAUDE.md/AGENTS.md	GLOSSARY.md	README.md	.cursor/*.mdc
Claude Code	✅ CLAUDE.md 優先	✅ CLAUDE.md 経由*	✅ 自動参照	❌
Cursor	✅ 参照可能	✅ .cursor/.mdc 経由*	✅ 自動参照	✅ 専用形式
GitHub Copilot	✅ AGENTS.md 経由***	✅ 自動参照	✅ 自動参照	❌
ChatGPT/Codex	✅ AGENTS.md 経由***	✅ AGENTS.md 経由***	✅ 手動で提供	❌

CLAUDE.md 経由: CLAUDE.md に「docs/GLOSSARY.md を必ず参照」と記載すれば自動で読み込み
**.cursor/.mdc 経由: .cursor/*.mdc に「docs/GLOSSARY.md を参照」と記載すれば読み込み
***AGENTS.md 経由: AGENTS.md に記載することで各 AI ツールも文脈を理解

実例：チームメンバーが異なるツールを使用

# チーム構成

- 開発者 A: Claude Code 使用（Mac）
- 開発者 B: Cursor 使用（Windows）
- 開発者 C: GitHub Copilot 使用（Linux）

# 共通のドキュメント（全員が参照）

docs/GLOSSARY.md # 用語定義
CLAUDE.md # プロジェクトルール
README.md # 基本情報

# 結果

→ 全員が同じ用語・ルールでコード生成
→ レビュー時の認識齟齬なし
→ 一貫性のあるコードベース

ツール移行時のゼロコスト

Cursor → Claude Code への移行例

# 移行前（Cursor使用中）
.cursor/
├── code-style.mdc
├── testing.mdc
└── context.mdc
CLAUDE.md           # 既に存在
docs/GLOSSARY.md    # 既に存在

# 移行作業
1. Claude Codeをインストール
2. 既存のCLAUDE.mdを自動認識
3. GLOSSARY.mdも自動参照
4. 即座に開発継続可能（学習コストゼロ）

AI ツールの組み合わせ使用

# 開発フェーズ別の使い分け
設計フェーズ:
  - Claude Code（対話的な設計相談）
  - CLAUDE.mdで設計方針を記録

実装フェーズ:
  - GitHub Copilot（インライン補完）
  - GLOSSARY.mdの用語に従って実装

レビューフェーズ:
  - Cursor（コードレビュー支援）
  - 全ツールが同じドキュメントを参照
# 結果：各ツールの強みを活かしつつ一貫性維持

将来の保証：標準化の重要性

## 5 年後も使える知識資産

### Markdown が選ばれる理由

1. **業界標準フォーマット**

   - GitHub が採用
   - 全エディタがサポート
   - 人間も読みやすい

2. **AI の学習データ**

   - 大量の Markdown で学習済み
   - 理解精度が最も高い
   - 将来の AI も確実に対応

3. **移行の容易さ**
   - プレーンテキスト
   - 変換ツール豊富
   - バージョン管理との相性

投資対効果（ROI）

初期投資:
- ドキュメント整備: 40時間
- GLOSSARY.md作成: 8時間
- CLAUDE.md作成: 4時間

リターン:
- ツール切り替えコスト: 0時間（通常40時間）
- 新メンバー学習時間: 50%削減
- AIツールライセンス: 柔軟に選択可能
- 知識資産の永続的価値

→ 投資回収期間: 2ヶ月以内※3

🚀 まとめ：今すぐ実践できる 3 つのステップ

ステップ 1：基本ファイルの作成（5 分で完了）

# プロジェクトルートで実行
touch CLAUDE.md
mkdir -p docs
touch docs/GLOSSARY.md
touch docs/ARCHITECTURE.md

ステップ 2：AI 指示書の初期設定（10 分で完了）

# CLAUDE.md の最小構成

## プロジェクト概要

[プロジェクトの説明]

## 必ず参照するドキュメント

- docs/GLOSSARY.md

## コーディングルール

- [あなたのルール]

ステップ 3：用語集の作成（15 分で完了）

# docs/GLOSSARY.md

## [主要なエンティティ名]

- 定義：
- 命名規則：
- 関連：

📈 ROI（投資対効果）

初期投資: 約 4 時間（ドキュメント整備）
リターン: 月間 160 時間の削減※2
投資回収期間: わずか 1 週間

注釈

※1 AI ツールの Markdown 参照について: 各 AI ツールの Markdown 参照機能は、ツールの設定や利用環境によって動作が異なります。Claude Code は CLAUDE.md を優先的に参照しますが、Cursor や GitHub Copilot では、エディタで開いているファイルや明示的に指定したファイルが参照対象となる場合があります。最適な設定については各ツールのドキュメントをご確認ください。

※2 ROI 計算の前提条件: チーム 5 名、各メンバーが 1 日あたり約 2 時間の AI 指示時間を削減（20 回 →3 回 = 85%削減）、月 8 時間稼働と仮定。実際の効果はチーム構成や業務内容により異なります。

※3 投資回収期間の試算: 初期投資約 52 時間、削減効果がチーム 5 名 ×1 日 2 時間 ×20 日稼働＝月 200 時間の場合。2 ヶ月以内の回収が可能。小規模チームではより長期間かかる場合があります。

結論: GitHub で Markdown ドキュメントを管理することで、AI ツールのベンダーロックインを回避し、チーム全体の生産性を最大化できます。2025 年の AI 駆動開発において、これは選択肢ではなく必須の実践です。

🔗 関連記事

Claude Code で開発効率 85%UP！ - AI との対話を最適化する実践テクニック

📣 フィードバック募集

この記事の手法を試された方は、ぜひコメントで結果を共有してください！皆様の実践例が、コミュニティ全体の知見となります。

著者について

🚀 AI 駆動開発を日々実践中のエンジニア

💼 業務：インフラ〜フロントエンドまで AI 駆動で開発
🏢 経験：GCP/AWS、オンプレインフラ構築、フルスタック開発
開発歴: ${new Date().getFullYear() - 2005}年〜
🎯 目標：AI 駆動開発のスペシャリストを目指して日々学習中
♟️ 趣味：囲碁（浦添囲碁会館で土曜大会参加）

📧 お仕事のご相談

AI 駆動開発のご相談、開発案件のお問い合わせはお気軽にどうぞ！

以下のような案件を承っております：

🌐 Web サイト・アプリケーション開発
🔄 既存システムの AI 活用リファクタリング
☁️ インフラ構築・最適化
💡 技術顧問・コンサルティング

連絡先:

📧 メール: info@foodit.co.jp
💬 Zenn: DM でお気軽に
🐙 GitHub: Issue またはメッセージ

フォローしていただけると嬉しいです！最新の AI 開発テクニックを共有していきます

📘 Zenn: この記事の著者をフォロー
🐙 GitHub: @sakumoto-shota