なせ(れ)ばなる

2026/05/07

# Devin 導入検討

---
## 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 / 月 |

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

2026/04/29

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

2026/03/22

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. 作業終了後、管理画面からそのアカウントを削除

2026/03/20

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でなくロール名を指定する**

2025/12/18

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を分離） |

2025/12/10

OpenSSL コマンドチートシート (PEM形式中心)

# OpenSSL コマンド チートシート (PEM形式中心)

## 証明書の表示
```bash
openssl x509 -in cert.pem -text -noout
```
- -in cert.pem : 入力する証明書ファイルを指定（PEM形式）
- -text : 証明書の詳細情報をテキスト形式で表示（Subject, Issuer, 有効期限, SANなど）
- -noout : 証明書本体（Base64エンコード部分）を出力しない

## CSR (証明書署名要求) の内容確認
```
openssl req -in request.csr -text -noout
```

## 秘密鍵の内容確認
```
openssl rsa -in private.key -check -noout
```
- -check : 秘密鍵の整合性を検証

## サーバー証明書の確認
```
openssl s_client -connect example.com:443 -servername example.com
```
- -connect host:port : 接続先ホストとポートを指定（HTTPSなら443）
- -servername host : SNI (Server Name Indication) を指定。複数ドメインを持つサーバーで正しい証明書を取得するために必要

証明書部分だけ抽出して詳細表示:
```
openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -text -noout
```

## 秘密鍵とCSR作成
```
openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr
```
- -new : 新しいCSRを作成
- -newkey rsa:2048 : 新しいRSA秘密鍵を生成（2048bit）
- -nodes : 秘密鍵を暗号化せずに保存（パスフレーズなし）
- -keyout server.key : 秘密鍵の出力先ファイル
- -out server.csr : CSRの出力先ファイル

## 証明書の検証
```
openssl verify -CAfile ca.pem cert.pem
```
- -CAfile ca.pem : 信頼するCA証明書を指定

## 形式変換 (PEM中心)
#### PEM → DER
```
openssl x509 -in cert.pem -outform der -out cert.der
```
- -outform der : 出力形式をDER (バイナリ) に指定

#### DER → PEM
```
openssl x509 -in cert.der -inform der -out cert.pem
```
- -inform der : 入力形式がDERであることを指定

## PFX / PKCS#12 関連
- **PKCS#12**：秘密鍵・証明書・証明書チェーンを1つの暗号化コンテナにまとめる標準規格
- **PFX / P12**：PKCS#12形式のファイルの呼び名（Windows/IISでは `.pfx`、Linux/OpenSSLでは `.p12` が一般的）

**※ PFX（PKCS#12）を扱うすべてのコマンドでは、PFX 作成時に設定されたパスワードが必要**
#### PFX (PKCS#12) → PEM（まとめて出力）
```
openssl pkcs12 -in cert.pfx -out cert.pem -nodes
```
- -in cert.pfx : 入力ファイル（PKCS#12形式）
- -nodes : 秘密鍵を暗号化せずに出力

#### PFX → 秘密鍵のみ
```
openssl pkcs12 -in cert.pfx -nocerts -out server.key
```

#### PFX → サーバー証明書のみ
```
openssl pkcs12 -in cert.pfx -clcerts -nokeys -out server.crt
```

#### PFX → 中間CA証明書（チェーン）
```
openssl pkcs12 -in cert.pfx -cacerts -nokeys -out chain.crt
```

#### 秘密鍵のパスワードを除去（Apache / Nginx用）
```
openssl rsa -in server.key -out server_nopass.key
chmod 600 server_nopass.key
```

#### 個々のファイル → PFX を作成
```
openssl pkcs12 -export \
  -inkey server.key \
  -in server.crt \
  -certfile chain.crt \
  -out cert.pfx
```
- 秘密鍵 + 証明書 + 中間CA を 1つの PFX にまとめる
- 実行時に PFX 用パスワードを設定

#### PFX の内容確認（復号せず表示）
```
openssl pkcs12 -in cert.pfx -info -noout
```
- 使用暗号方式（TripleDES / AES256）
- 証明書構成
- MAC iteration 回数

#### 鍵と証明書の一致確認
```
openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa  -noout -modulus -in server_nopass.key | openssl md5
```
- 両方のハッシュが一致すれば OK

## 自己署名証明書
### ダミー証明書の作成（自己署名証明書を一度に生成）
```
openssl req -x509 -newkey rsa:2048 -nodes -keyout dummy.key -out dummy.crt -days 365 -subj "/CN=example.com"
```
- 秘密鍵と自己署名証明書を同時に生成
- -x509 : CSRではなく自己署名証明書を直接出力
- -days 365 : 有効期限を365日に設定
- -subj : 対話入力を省略してDNを指定（例: CN=example.com）

### 通常の3ステップの流れ
```
# (1) 秘密鍵を生成
openssl genrsa -out server.key 2048

# (2) CSRを生成
openssl req -new -key server.key -out server.csr -subj "/CN=example.com"

# (3) CSRを秘密鍵で署名して自己署名証明書を作成
openssl x509 -req -in server.csr -signkey server.key -out server.crt -days 365
```

2025/12/09

curlコマンドチートシート

## 基本操作
- **GETリクエスト**
  ```bash
  curl https://example.com
  ```


- レスポンスをファイル保存
  ```
  curl https://example.com -o output.txt
  ```

- 詳細表示（デバッグ用）
  ```
  curl -v https://example.com
  ```

---
## ヘッダー関連
- レスポンスヘッダーのみ表示
  ```
  curl -I https://example.com
  ```

- リクエストヘッダー追加
  ```
  curl -H "Authorization: Bearer TOKEN" https://example.com
  ```

---
## 認証
- BASIC認証
  ```
  curl -u user:password https://example.com
  ```

- Cookie認証
  ```
  curl -c cookie.txt -d "id=user&pw=pass" https://example.com/login
  curl -b cookie.txt https://example.com/data
  ```

---
## HTTPメソッド指定
- POSTリクエスト
  ```
  curl -X POST -d "key=value" https://example.com
  ```

- JSONデータ送信
  ```
  curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' https://example.com/api
  ```

- PUTリクエスト
  ```
  curl -X PUT -d @file.json https://example.com/api
  ```

---
## ファイル操作
- ダウンロード（元のファイル名を保持）
  ```
  curl -O https://example.com/file.zip
  ```

- 複数ファイルダウンロード
  ```
  curl -O URL1 -O URL2
  ```

---
## その他便利オプション
- リダイレクトを追跡
  ```
  curl -L https://short.url
  ```

- 通信内容をダンプ
  ```
  curl --trace-ascii - https://example.com
  ```

- 処理時間を表示
  ```
  curl -w "%{time_total}\n" https://example.com
  ```

- SSL検証を無視（テスト用途のみ推奨）
  ```
  curl -k https://example.com
  ```

登録: 投稿 (Atom)

なせ(れ)ばなる

2026/05/07

2026/04/29

Marp for VS Code

2026/03/22

TrendAI Vision One™ (PAYG)

2026/03/20

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

2025/12/18

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

2025/12/10

OpenSSL コマンドチートシート (PEM形式中心)

2025/12/09

curlコマンドチートシート

人気の投稿

リンク集

ラベル

2026/05/07

2026/04/29

Marp for VS Code

2026/03/22

TrendAI Vision One™ (PAYG)

2026/03/20

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

2025/12/18

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

2025/12/10

OpenSSL コマンド チートシート (PEM形式中心)

2025/12/09

curlコマンドチートシート

人気の投稿

OpenSSL コマンドチートシート (PEM形式中心)