GitHub, GitHub Copilot, Devinの契約フロー

## ユースケース
- 契約プラン
  - GitHub: Team
  - GitHub Copilot: Business
  - Devin: Teams

---

## 契約フロー

### 1. GitHub の契約

1. 管理者が GitHub 個人アカウントを作成（Free）
2. 管理者が Organization を作成  
   - "This organization belongs to:" で Business / Company を選択
3. 管理者が 開発者（10名）を Organization に招待
4. 開発者が GitHub アカウントを作成（未保有の場合）
5. 開発者が 招待を承認し Organization に参加
6. 管理者が GitHub Team プランへアップグレード  
   - このタイミングで決済情報（クレジットカード等）を登録

---

### 2. GitHub Copilot（Business）の契約・有効化

1. 管理者が GitHub Organization 上で Copilot Business を契約
   （※ GitHub に登録済みの決済情報が利用される）
2. 管理者が 必要なユーザー数分のライセンス（Seat）を購入
3. 管理者が 開発者に Copilot を割り当て（有効化）
4. 管理者が （任意）ポリシー設定および追加課金（overage）の許可／禁止を設定
5. 開発者が GitHub アカウントを通じて Copilot を利用可能になる

---

### 3. Devin（Teams）の契約・連携設定

1. 管理者が Devin アカウントを作成
2. 管理者が 決済情報（クレジットカード等）を登録
3. 管理者が Devin Teams プランを契約
4. 管理者が Devin 上で Organization（案件単位）を作成
5. 管理者が GitHub と連携（GitHub App のインストール）
6. 管理者が 対象リポジトリへのアクセス権を設定
7. 開発者が Devin を利用可能になる

---

### 4. 課金の発生構造

| サービス | 契約主体 | 課金単位 | 課金の性質 |
|---|---|---|---|
| GitHub | Organization | ユーザー（Seat） | 固定費（人数比例） |
| GitHub Copilot | Organization | ユーザー（Seat）＋組織共有利用枠 | サブスク＋従量（超過時） |
| Devin | Organization | 利用量（タスク実行量） | 従量課金（最低利用額あり） |

---

### 5. ポイント

- すべての契約は Organization（企業）単位で実施される
- 開発者は契約主体ではなく、管理者による割当を受けて利用する
- GitHubは最初にFreeで開始し、Organization作成後にTeamへアップグレードすることで課金が発生する 
- GitHub と GitHub Copilot は **同一の決済情報（GitHub側）で課金される**
- Devin は **別サービスのため、別途決済情報の登録が必要**
- Copilot の追加課金（従量）も GitHub の決済情報に対して発生する
- すべての支払いは Organization 単位で集約される（個人ではない）
- GitHub と GitHub Copilot はユーザー（アカウント）を前提とした契約
- Devin はユーザーではなく利用量（タスク）に紐づく契約
- GitHub Copilot の利用枠はユーザー単位ではなく、Organization 単位で共有される

Windows上でVIエディターを使用する（gvim）

# インストール
[https://www.vim.org/download.php](https://www.vim.org/download.php)

# カスタマイズ

1. Vimの設定ファイル（_vimrc）を作成
**ファイルパス**: C:\Users\(ユーザー名)\\_vimrc
```
set nobackup
set nowritebackup
set noswapfile
set noundofile
set clipboard=unnamed
```

* set nobackup
  ファイルを上書き保存したときに、古い内容を保存する「バックアップファイル（末尾に~が付くもの）」を作成しない。
* set nowritebackup
  保存処理の最中だけ一時的に作成されるバックアップファイルも作成しない（保存失敗時のリスクヘッジ用ファイルを無効化する）。
* set noswapfile
  編集中にクラッシュした際の復旧用ファイル（.swp）を作成しません。これにより、他のアプリで開いている警告などが出にくくなる。
* set noundofile
  GVimを一度閉じた後も「元に戻す(Undo)」ができるように履歴を残すファイル（.un~）を作成しない。
* set clipboard=unnamed
  Vim内のヤンク（y）や削除（d）を、Windows標準のクリップボードと常に連動させる。
  
```
set guicursor=n-v-c:block-blinkon0,i-ci:ver25-blinkon0
set cursorline
set hlsearch
```

* set guicursor=n-v-c:block-blinkon0,i-ci:ver25-blinkon0
  挿入モード（文字入力中）は縦棒、ノーマルモードはブロック型で、どちらも点滅させない。
  a: すべてのモード（ノーマル、挿入、コマンドラインなど）を対象にする。
  blinkon0: 点滅をオフ（常に点灯）にする。
* set cursorline
  現在の行に下線（またはハイライト）を表示する。
* set hlsearch
  検索結果をハイライト（色付け）する。

```
set guifont=MS_Gothic:h10
set background=dark
colorscheme desert
highlight Normal guifg=#f5f5f5
```
* set guifont=MS_Gothic:h10
  フォント名:hサイズ の形式でフォントの種類とサイズを指定する。
* set background=dark
  背景が「light」か「dark」かを伝えて文字色のトーンを自動調整する。
* colorscheme desert
  デザインパック（desert/ron/slate/industryなど）を適用する。
* highlight Normal guifg=#f5f5f5
  特定の要素（コメント、行番号、背景など）の色や装飾を個別に指定する。

```
" set guicursor=a:blinkon0
```
Vimの設定ファイル（_vimrc）にコメントを記載するには、ダブルクォーテーション " を置く。

システム開発へのDevinとGitHub Copilotの導入

## 1. プロダクトの位置づけ（Devin vs GitHub Copilot）

| 観点 | Devin | GitHub Copilot |
|---|---|---|
| 基本思想 | 自律型AIソフトウェアエンジニア（タスク委任） | IDE内AIアシスタント＋GitHub連携エージェント |
| 人との役割分担 | AIが実装主体、人は指示・レビュー | 人が実装主体、AIが補助 |
| 作業単位 | 課題／チケット（タスク単位） | 行・関数・PR単位 |
| 非同期実行 | ◎（自律実行・完了通知） | △（人主導での非同期処理） |

---
## 2. システム開発工程と照らした適用整理

プロダクトの思想が異なるため、Devin と GitHub Copilot は
システム開発工程において得意とする領域が異なる。

---
### 2.1 開発工程別の得意分野比較

| 開発工程 | 主な作業内容 | Devin | GitHub Copilot |
|---|---|---|---|
| 要件整理・調査 | 既存コード理解、影響調査 | ◎ | △ |
| 基本設計 | 方針案作成、構成整理、Issue分割 | ◎ | △ |
| 詳細設計 | クラス設計、API設計 | ○ | ○ |
| 実装 | 新規実装、ロジック追加 | ○ | ◎ |
| 単体テスト | テスト生成、修正反復 | ○ | ◎ |
| 結合テスト | バグ修正、原因特定 | ○ | ◎ |
| リファクタリング | まとまった改修 | ◎ | ○ |
| コードレビュー | PRレビュー、軽微修正 | △ | ◎ |
| 保守・運用 | 小修正、定常作業 | △ | ◎ |

※ ◎：特に得意／○：利用可能／△：主用途ではない

---
### 2.2 開発工程におけるツールの位置づけ

Devin および GitHub Copilot を併用することで、
システム開発工程全体をツールとして広くカバーすることができる。

ただし、各ツールの役割は「開発工程を完全に置き換える」ことではなく、
人が担う設計判断・優先順位決定・品質責任を前提とした上で、
開発作業を補完・支援・高速化する点にある。

そのため、工程ごとに適したツールを使い分け、
人と AI が協調して開発を進めることを前提とする。

---
### 2.3 SI企業における実務的な使い分け

- 調査、設計補助、影響分析、方針が定まったタスク単位の改修：
  Devin を活用して非同期・並列に作業を委任する

- 日常的な実装、軽微な修正、レビュー対応、即時の試行錯誤：
  GitHub Copilot を活用して人が主導して進める

両者は代替関係ではなく、補完関係として併用する。

---
## 3. 使用モデルの扱い方

| 観点 | Devin | GitHub Copilot |
|---|---|---|
| モデル選択 | 非公開（内部で最適化。利用者が選択する必要なし） | ユーザー選択（GPT / Claude 等を用途に応じて切替） |
| 設計思想 | 成果物・完遂重視（モデルの違いを意識させない） | 対話品質・即時性重視（モデル特性を活かす） |
| ガバナンス | ◎（モデル選択を意識せずに統制可能） | △（モデル選択方針の整理が必要） |

※ Devin はモデルを意識しない委任型運用を前提とするのに対し、  
※ GitHub Copilot はモデル選択も開発者の判断に含めた活用となる

---
## 4. 契約プラン・料金体系

### 4.1 Devin（2026年4月以降・公式最新体系）

Devin は 2026年4月14日にセルフサーブ向け契約体系を刷新。
従来の Core / Team プランは廃止され、以下の体系へ移行した。

出典：Cognition公式ブログ  
https://cognition.ai/blog/new-self-serve-plans-for-devin

---
#### Devin（プラン構成）
| プラン | 課金方式 | 金額 |
|---|---|---|
| Free | 無料 | $0 |
| Pro | 月額サブスクリプション（利用枠付き） | $20 / 月 |
| Max | 月額サブスクリプション（利用枠付き） | $200 / 月 |
| Teams | 利用量ベース（最低利用額あり） | 最低 $80 / 月 |
| Enterprise | 個別契約 | 見積 |

※ Free / Pro / Max は個人用途のプラン、利用枠超過分は従量課金
※ Teams プランは 1 契約の中で複数の Organization を作成可能で、
   Organization 単位で利用量を管理しつつ、請求は契約全体で合算される利用量ベースのプラン

---
### 4.2 GitHub Copilot（2026年6月以降・料金体系改定予定）

GitHub Copilot は 2026年6月より、
従来の定額課金を基本としつつ、一部の高度なエージェント機能については利用量に応じた従量課金（GitHub AI Credits）へ移行する。

通常のコード補完やチャットなどの基本機能については、引き続き各プランの月額料金に含まれるが、高度機能は利用枠（GitHub AI Credits）を消費し、超過分は従量課金となる。

出典：GitHub公式ドキュメント  
https://docs.github.com/en/copilot/concepts/billing/usage-based-billing-for-organizations-and-enterprises

--- 
#### GitHub Copilot（プラン構成）

| プラン | 課金方式 | 価格 |
|---|---|---|
| Free | 無料（利用枠付き） | $0 |
| Pro, Pro+ | 月額サブスクリプション（利用枠付き） | $10 / 月, $39 / 月 |
| Business | ユーザー単位・月額（利用枠付き） | $19 / ユーザー |
| Enterprise | ユーザー単位・月額（利用枠付き） | $39 / ユーザー |

※ Free / Pro / Pro+ は個人利用向けのプラン
※ Business はチーム単位でのポリシー適用が可能な組織向けプラン  
※ Enterprise は企業全体での統制・監査機能を備えた上位プラン
※ 高度機能は利用枠（GitHub AI Credits）を消費し、超過分は従量課金
※ Business / Enterprise の利用枠はユーザー単位でなく組織単位で共有

---
## 5. チーム単位でのコスト制御・ガバナンス
| 観点 | Devin | GitHub Copilot |
|---|---|---|
| 請求単位 | Teams 契約（合算） | ユーザー（Seat単位） |
| 管理・配賦単位 | **Organization** | **Organization（利用枠は共有）** |
| 月額上限管理 | ◎（Org 単位で利用量を制御） | △（上限設定は不可、費用の可視化のみ） |
| 案件別切り分け | ◎（Org 分離） | △（利用枠が組織共有のため、案件単位での利用量・コスト分離は困難） |
| 利用量の可視化 | ◎（Org 別） | ◎（ユーザー別＋組織単位） |

---
## 6. ソースコード管理（リポジトリ）

### 6.1 SCM（GitHub）連携の観点での整理

| 観点 | Devin | GitHub Copilot |
|---|---|---|
| 内蔵SCM | なし | なし |
| GitHub連携方式 | GitHub App | GitHubネイティブ |
| PR作成 | 自動（Devinが作成） | 自動（Copilot Agent） |
| レビュー前提 | 必須 | 必須 |

---
### 6.2 Devin / GitHub Copilot に必要な GitHub 契約プラン
Devin および GitHub Copilot は、GitHub をソースコード管理基盤として利用する。そのため、GitHub との契約が別途必要となる。  
出典：GitHub公式 Pricing（ https://github.com/pricing ）

| GitHub プラン | 料金 | 主な用途 |
|---|---|---|
| GitHub Free | $0 | 個人・OSS |
| GitHub Team | $4 / ユーザー / 月 | チーム・商用開発 |
| GitHub Enterprise | $21 / ユーザー / 月 | 企業・SI（SSO・監査） |

※ GitHub Team では、レビュー必須化、Code Owners、複数レビュア指定など、チーム開発向けの追加機能が提供される（Free では対象外）  
※ GitHub Enterprise では、SSO（IdP連携）、監査ログ、組織横断の権限制御など、企業・SI利用を前提とした統制機能が提供される

---
### 6.3 Devin / GitHub Copilot 別の GitHub プラン要件

| 利用内容（Devin / GitHub Copilot） | 必要な GitHub プラン |
|---|---|
| Devin（GitHub リポジトリで作業・PR作成） | GitHub Team 以上 |
| GitHub Copilot Business | GitHub Free / Team / Enterprise |
| GitHub Copilot Enterprise | GitHub Enterprise 必須 |

※ Devin / GitHub Copilot はいずれも GitHub 上の既存リポジトリ・権限・ブランチ保護ルールを継承  
※ GitHub Copilot Enterprise は GitHub Enterprise Cloud のみ対応
　（GitHub Enterprise Server では利用不可）

---
## 7. チケット管理
| 観点 | Devin | GitHub Copilot |
|---|---|---|
| 内蔵機能 | なし | なし |
| 主連携 | GitHub Issues / Jira / Linear | GitHub Issues |
| 委任型運用 | ◎（チケット単位で実装まで委任可能） | △（人主導での補助が中心） |
| チケット→実装 | ◎（Issue起点で実装・PR作成） | ◎（Issue参照で実装支援） |

※ GitHub Issues は GitHub Free プランから利用可能であり、チケット管理機能自体に追加費用は発生しない。組織的な権限制御や監査が必要な場合は Team / Enterprise プランを利用する。

---
## 8. SI企業・プロジェクト視点での整理

これまでの整理を踏まえ、案件・プロジェクト運営の観点から、
SI企業における両プロダクトの位置づけを整理する。

| 観点 | Devin | GitHub Copilot |
|---|---|---|
| 案件単位ガバナンス | ◎（Org による案件単位の管理が可能） | △（ユーザー単位管理が前提） |
| コスト上限管理 | ◎（Org 単位で運用・配賦可能） | △（人数比例で間接的） |
| 日常開発支援 | △（タスク委任が中心） | ◎（実装・レビューの即時補助） |
| 並列化・スケール | ◎（非同期・並列委任が可能） | △（人の作業量に依存） |


※ 両者は対立関係ではなく、補完関係にある  
※ GitHub Copilot：日常的な実装・レビュー作業の底上げ  
※ Devin：案件単位の作業委任・並列化による生産性向上

---
## 9. 月額コスト内訳（開発者10名のケース）

| 開発工程 | 利用サービス | 契約プラン | 価格（月額） |
|---|---|---|---:|
| 要件・課題整理 | GitHub Issues | GitHub Team | $4 × 10 = $40 ※共通 |
| 設計・調査・影響分析 | **Devin** | **Devin Teams** | **$80〜** |
| 実装・修正・レビュー | **GitHub Copilot** | Business | $19 × 10 = $190〜 |
| コード管理・PR | GitHub | GitHub Team | $4 × 10 = $40 ※共通 |
|  |  | **合計** | **$310 / 月〜** |

※ GitHub Issues は GitHub 契約に含まれる（追加費用なし）  
※ GitHub：ユーザー数に比例する固定費  
※ GitHub Copilot：月額サブスクリプション（利用枠付き）、利用枠超過分は従量課金で追加費用が発生（変動費）  
※ Devin：利用量に応じて増加する変動費

---
### 9.x 変動費を含めた月額コストの目安（参考）

| 想定利用レベル | Devin 月額 | Copilot 増分 | 全体合計（目安） |
|---|---:|---:|---:|
| 軽めの活用（設計・調査中心） | $100〜150 | 小 | $410〜490 / 月 |
| 標準的な活用（調査＋一部実装） | $200〜300 | 中 | $510〜650 / 月 |
| 重めの活用（並列実装・リファクタ） | $400〜600 | 中〜大 | $710〜1000 / 月 |

※ 実際の金額はタスク内容・委任頻度により変動

Marp for VS Code

# Marp for VS Code クイックチートシート

Marp for VS Code を使って Markdown からスライドを作成する際の  
**よく使う記法・調整方法をまとめたチートシート**です。

---

## Front Matter（基本設定）

Front Matter は **省略可能** ですが、  
テーマ指定やページ番号表示などを行う場合に使用します。

    ---
    marp: true          # Marpを有効化（VS Code拡張では省略可能）
    theme: default      # テーマ（default / gaia / uncover）
    paginate: true      # ページ番号を表示
    header: "タイトル"  # ヘッダー（任意）
    footer: "フッター"  # フッター（任意）
    ---

---

## 改ページと表示制御（Marp使用時）

    ---     # 通常の改ページ

    ___     # ヘッダー・フッター・ページ番号を非表示にして改ページ

---

## 文字配置・簡易レイアウト

Marp では HTML を使用できます。

**中央寄せ**

    <div style="text-align:center">
    中央揃えテキスト
    </div>

---

## 画像の扱い（Marp拡張）

**サイズ指定**

    ![width:400px](image.png)

**複数画像の横並び**

    ![](a.pngbg](image.png)

**背景画像＋明るさ調整**

    ![bg brightness:0.6](image.png)

---

## スライド全体の余白を調整

スライド外周の余白を減らし、表示領域を広げます。

    <style scoped>
    section {
      padding: 30px;
    }
    </style>

---

## 表のサイズ・視認性調整

表がスライドからはみ出る場合の定番設定。

    <style scoped>
    table {
      font-size: 60%;
    }
    table th,
    table td {
      padding: 4px 8px;
    }
    </style>

---

## 個別スライド専用スタイル（Marp）

特定のスライドでのみ CSS を適用したい場合に使用します。

    <style scoped>
    h1 {
      color: #0066cc;
    }
    </style>

---

## その他のオプション例

**スライドサイズ指定（16:9）**

    ---
    size: 16:9
    ---

※ Front Matter 内に記述

---

## 参考リンク

- Marp 公式  
  https://marp.app

- Marp for VS Code  
  https://marketplace.visualstudio.com/items?itemName=marp-team.marp-vscode

TrendAI Vision One™ (PAYG)

# サインイン画面
[TrendAI Vision One™ サインイン](https://signin.v1.trendmicro.com/)

# サブスクリプションの種類
- 従量課金（PAYG）
[TrendAI Vision One™ (PAYG)](https://aws.amazon.com/marketplace/pp/prodview-vs2l7sl2ogwvg)
- 12カ月契約
[TrendAI Vision One™](https://aws.amazon.com/marketplace/pp/prodview-u2in6sa3igl7c)

|ディメンション|説明|費用/単位|
|----|----|----|
|Endpoint Security - Small|EC2インスタンス（マイクロからミディアム）、ワークスペース、またはその他のクラウド（1 vCPU）あたり1時間あたり|$0.011|
|**Endpoint Security - Medium**|EC2インスタンス（大規模）、ワークスペース、またはその他のクラウド（2 vCPU）あたり1時間あたり|**$0.032**|
|Endpoint Security - Large|EC2 インスタンス (XL)、ワークスペース、またはその他のクラウド (4 vCPU) あたり 1 時間あたり|$0.047|

\$0.032 * 24 * 30 = \$23.04/月
\$23.04 * 150 = 3,456/月

# 新規導入の流れ
## 1. サブスクライブ
1. AWS Marketplaceから「TrendAI Vision One™ (PAYG)」を検索
2. TrendAI Vision One™ (PAYG) から「購入オプションを表示」
3. サブスクライブを選択

## 2. サブスクリプションをTrend Vision Oneへリンク
1. アカウントを所有していればTrend Vision Oneへサインイン、なけばサインアップ
2. TrendAI Vision One™ (PAYG)を有効化（アカウントへ通知メールが届く）
3. コンソールをプロビジョニングする地域を選択

## 3. AWSアカウントを連携
1. Cloud Security → Cloud Accounts → Add Cloud Account
2. CloudFormationよりスタックを起動

## 4. 製品インスタンスを作成
1. インスタンスタイプに「Server & Workload Protection」を選択して製品インスタンスを作成

## 5. ポリシー作成と割当
1. [Endpoint Security] → [Server & Workload Protection] → [ポリシー]より
2. 継承元ポリシーを選択
3. 既存のコンピュータの現在の設定を、このポリシーのベースにする場合はYESとしてコンピュータを選択（既存コンピュータがなければNoで可）
4. 不正プログラム対策などの試行設定を選択
5. コンピュータへ手動でポリシーを割り当てる場合は、[コンピュータ] → [処理] → [ポリシーの割り当て] を選択し、上で設定したポリシーを適用

## 6. エージェントインストールおよびポリシー割り当て（デプロイスクリプトを使用）
エージェント導入方法は2通りあり
### エージェントを手動インストールする方法
この場合、ポリシー割り当ては別途手動で適用となる
[Trend Micro Vision One Endpoint Agent (Linux版) インストール手順](https://success.trendmicro.com/ja-JP/solution/KA-0011571)

### デプロイメントスクリプトを使用する方法
[デプロイメントスクリプトを使用してエージェントをデプロイする](https://docs.trendmicro.com/ja-jp/documentation/article/trend-vision-one-using-endpoint-deployment-script)
1. [Endpoint Security] → [Endpoint Inventory] → [エージェントインストーラ]より
2. [Deployment Script]を選択
3. 保護タイプに「Server & Workload Protection」を選択し、OSやProtection Manager、エージェントポリシーを選択
4. シェルスクリプトをダウンロード
5. ダウンロードしたシェルスクリプトをEC2上で実行

### エージェントのアンインストール方法
[Linuxエージェントを手動でアンインストールする](https://docs.trendmicro.com/ja-jp/documentation/article/trend-vision-one-manually-uninstall-linux-agents#task_rpp_5zq_pgc)

# 外部ユーザへ一時的な操作権限を与える方法
1. [Administration] → [User Accounts] → [Add User]より
2. ローカルアカウントを選択、メールアドレス及び必要な権限を付与して招待メールを送信
3. 招待メールの確認リンクを24時間以内に押下し、パスワードを設定
4. 作業終了後、管理画面からそのアカウントを削除

AWSでクロスアカウントアクセス

# アクセスされる側
- クロスアカウント用のロールを作成
  - [信頼されたエンティティタイプ]に「AWS アカウント」を指定
  - 許可ポリシーを指定
  - 信頼ポリシーを指定
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<許可するアカウントID>:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}
```

# アクセスする側
- 許可ポリシーを作成し、対象ユーザへ割当
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::<ロールを所有するアカウントID>:role/<ロール名>"
        }
    ]
}
```
- ロールの切替
**注）IAMロール名にはARNでなくロール名を指定する**

GPT‑5.2（Responses API）利用の流れ

GPT‑5.2（Responses API）利用の流れ
## 利用手順
- OpenAI アカウントを作成
- APIキー を取得
- リクエストヘッダーに設定
  - Authorization: Bearer YOUR_API_KEY
  - Content-Type: application/json

## エンドポイント
```
POST https://api.openai.com/v1/responses
```

## 公式ドキュメントURL
- [OpenAI API Docs – Responses](https://platform.openai.com/docs/api-reference/responses)

## Pythonコード例
### requests を使った直接呼び出し
```
import requests

API_KEY = "YOUR_API_KEY"
url = "https://api.openai.com/v1/responses"
headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}

# ユーザー質問
user_question = "この製品はISO規格に適合していますか？"

# RAGで取得した外部情報（例: 構造データ＋PDF抜粋）
retrieved_context = """
構造データ:
{
  "製品名": "ABCセンサー",
  "測定範囲": "0-100℃",
  "精度": "±0.5℃"
}

規格PDF抜粋:
ISO 12345:2023 セクション 4.2
温度センサーは測定範囲0-100℃、精度±1.0℃以内であること。
"""

# API呼び出し
data = {
    "model": "gpt-5.2",
    "input": f"質問: {user_question}\n\n追加情報:\n{retrieved_context}"
}

response = requests.post(url, headers=headers, json=data)
print(response.json()["output"][0]["content"][0]["text"])
```
「"""」は三連引用符。複数行にわたる文字列を定義する。

### 公式Python SDKを使った呼び出し
```
from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY")

# ユーザー質問
user_question = "この製品はISO規格に適合していますか？"

# RAGで取得した外部情報（例: 構造データ＋PDF抜粋）
retrieved_context = """
構造データ:
{
  "製品名": "ABCセンサー",
  "測定範囲": "0-100℃",
  "精度": "±0.5℃"
}

規格PDF抜粋:
ISO 12345:2023 セクション 4.2
温度センサーは測定範囲0-100℃、精度±1.0℃以内であること。
"""

# API呼び出し
resp = client.responses.create(
    model="gpt-5.2",
    input=f"質問: {user_question}\n\n追加情報:\n{retrieved_context}"
)

print(resp.output[0].content[0].text)
```

### API呼出し時のinputの指定パターン
#### 文字列形式
```
resp = client.responses.create(
    model="gpt-5.2",
    input=f"質問: {user_question}\n\n追加情報:\n{retrieved_context}"
)
```
「f」は変数展開の指定

#### 構造化形式
```
resp = client.responses.create(
    model="gpt-5.2",
    input=[
        {
            "role": "user",
            "content": [
                {"type": "input_text", "text": f"質問: {user_question}"},
                {"type": "input_text", "text": f"追加情報:\n{retrieved_context}"}
            ]
        }
    ]
)
```
#### roleの種類
1. role: "system"
  - 用途: モデルの振る舞いや出力ルールを事前に定義する
  - 関係性:
    - スキーマで「構造」を保証するだけでは不十分
    - 「このプロパティはこういう意味で、この範囲の値を返す」といった 意味付けや利用方法を指示する場所が system

2. role: "user"
  - 用途: 実際の質問や指示を与える
  - 関係性: プロパティの意味付けはここではなく、質問内容を渡す場所

3. role: "assistant"
  - 用途: 過去の応答を含めて会話の流れを維持する
  - 関係性: プロパティの意味付けとは直接関係しない

例:
```
"response_format": {
  "type": "json_schema",
  "json_schema": {
    "name": "iso_check_schema",
    "schema": {
      "type": "object",
      "properties": {
        "compliance": { "type": "boolean" },
        "standard": { "type": "string" },
        "explanation": { "type": "string" }
      },
      "required": ["compliance", "standard"]
    }
  }
}

"input": [
  {
    "role": "system",
    "content": [
      {
        "type": "text",
        "text": "あなたは品質管理の専門家です。必ず以下のスキーマに従って返答してください。\n- compliance: 製品が指定されたISO規格に適合している場合はtrue、そうでなければfalse。\n- standard: 対象となるISO規格番号を文字列で返す。\n- explanation: 適合／非適合の理由を簡潔に説明する。"
      }
    ]
  },
  {
    "role": "user",
    "content": [
      {
        "type": "input_text",
        "text": "この製品はISO 9001に適合していますか？"
      }
    ]
  }
]
```
#### system 指示の有効範囲
- リクエスト単位で有効
  → そのリクエストの中で指定した role: "system" の内容は、そのリクエスト全体に効きます。
- 次のリクエストには引き継がれない
  → 別の呼び出しをするときには、再度 system を含めて渡さないとルールは維持されません。
- 継続利用したい場合
  → 会話履歴を再現する形で、毎回 system を含めて送る必要があります。
  → 例えば「必ずJSON Schemaに従って返答する」「confidenceは0.0〜1.0で返す」といったルールは、毎回 system に書いて渡すのが正しい使い方です。

#### typeの種類
- input_text
  - 通常のテキスト入力
  - 例: ユーザーの質問や補足情報
- input_image
  - 画像入力
  - 例: 画像ファイルを渡して「この図を説明して」と指示する
- input_audio
  - 音声入力
  - 例: 音声ファイルを渡して「文字起こしして」と指示する

### file_searchの使い方
file_searchはResponses API に組み込まれたビルトインツール。Vector Store 内のファイルを検索し、回答生成に利用する仕組み。

1. Vector Store を作成

	```
	vs = client.vector_stores.create(name="my_store")
	```
    
2. ファイルをアップロードして Vector Store に追加
	```
	client.vector_stores.files.upload(
    	vector_store_id=vs.id,
   		file=open("manual.md", "rb")
	)
	```
    
3. Responses API 呼び出し時に tools と vector_store_ids を指定
```
resp = client.responses.create(
   	model="gpt-5.2",
   	input="この製品はISO 9001に適合していますか？",
   	tools=[{"type": "file_search"}],
   	vector_store_ids=[vs.id]
)
```

## GPT‑5.2 Responses API パラメータ一覧
1. 出力制御系
  - temperature
    - 出力のランダム性を制御（0〜2）
    - 低いほど安定・事実寄り、高いほど創造的
  - top_p
    - 確率分布の累積で候補範囲を制限（0〜1）
    - 低いほど一貫性が高く、高いほど多様性が増す
  - max_output_tokens
    - 出力の最大トークン数を指定
    - 長文生成や要約の長さを調整可能

2. 応答形式系
  - input
    - ユーザーからの質問や指示（必須）
  - modalities
    - 出力形式を指定（例: "text", "json", "audio"）
    - JSON構造や音声出力を求める場合に利用
  - response_format
    - 出力の形式をさらに細かく指定
    - 例: "json_schema" を指定して構造化データを返す

3. 応答数・多様性系
  - n
    - 応答の候補数を指定（例: 2なら2通りの回答を返す）
  - presence_penalty
    - 新しいトピックや単語を使う傾向を強める（-2〜2）
    - 高い値 → 繰り返しを避け、新しい語彙を導入
  - frequency_penalty
    - 同じ単語の繰り返しを抑制（-2〜2）
    - 高い値 → 冗長な繰り返しを減らす

4. ストリーミング系
  - stream
    - 出力を逐次受け取るかどうか（True/False）
    - チャットUIなどで「少しずつ表示」したい場合に利用

5. システム制御系
  - model
    - 使用するモデルを指定（例: "gpt-5.2", "gpt-5.2-pro", "gpt-5.2-mini"）
  - metadata
    - リクエストに付随するメタ情報（ログやトラッキング用）

## モデルバリエーション比較

|モデル名|特徴|用途例|
|----|----|----|
|gpt-5.2-mini| 軽量・低コスト   | チャットボット、リアルタイム応答|
|gpt-5.2| 標準精度・速度   | 一般的なテキスト生成、要約|
|gpt-5.2-pro| 長文脈・高精度   | 複雑な推論、研究支援、コード生成|

## GPT‑5.2 Responses API 価格（2025年12月時点）
|モデル名|入力 (1M tokens)|キャッシュ入力 (1M tokens)|出力 (1M tokens)|特徴|
|----|---:|---:|---:|----|
|GPT‑5.2|$1.75|$0.175|$14.00|標準モデル。複雑な推論やコーディングに強い|
|GPT‑5.2 Pro|$21.00| – |$168.00|最も精度が高い。専門的タスク向け|
|GPT‑5 Mini|$0.25|$0.025|$2.00|軽量・高速。コスト効率重視|

# RAGについて
## RAGは設計パターン
RAG（Retrieval‑Augmented Generation）は、LLMに渡す前処理の仕組み。「検索（Retriever）で外部情報を取得し、それをLLM（Generator）に渡して回答を生成する」という仕組みのこと。

## 実装パターン
実装の仕方は以下２パターン、或いはハイブリッド方式。

1. 利用者側で追加情報を与える方式
  - 特徴
  　- ユーザーが自分で検索・抽出した情報を input に含めて渡す
  　- GPT‑5.2（Responses API）は「質問＋追加情報」を受け取り回答するだけ
  - メリット
  　- シンプルで制御しやすい
  　- どの情報を根拠にするか利用者が明示できる
  - デメリット
  　- ユーザーが毎回情報を準備する必要がある
  　- 自動化には不向き

2. システム側で追加情報を付加する方式
  - 特徴
  　- ユーザーは質問だけを投げる
  　- システムが裏側で Retriever を動かし、関連情報を検索して input に自動で付加
  - メリット
  　- ユーザーは「質問するだけ」で済む
  　- 一貫した検索・根拠付けが可能
  - デメリット
  　- 検索精度がシステム依存になる
  　- どの情報が根拠に使われたかユーザーが見えにくい

3. 補足
  - GPT‑5.2（Responses API）は 与えられた input のテキストだけを処理します。
  - 「RAGで検索して付加して」と指示しても、API単体では外部データベースやPDFを勝手に検索する機能はありません。
  - RAGは 設計パターンなので、Retriever（検索部分）は利用者やシステム側で実装し、その結果を input に含める必要があります。

## CopilotのWeb検索統合 vs RAG設計パターン
| 項目         | CopilotのWeb検索統合                     | RAG設計パターン                          |
|--------------|------------------------------------------|------------------------------------------|
| 検索の実装   | Copilot内部で自動呼び出し                | 利用者／システムが外部で実装             |
| ユーザー操作 | 検索を意識せずに利用可能                 | 検索結果を明示的に input に含める必要あり |
| 出典提示     | CopilotがURLを提示                       | 開発者が出典を含める設計にする            |
| 設計思想     | 機能統合型（検索＋生成が一体）           | パターン分離型（RetrieverとGeneratorを分離） |