AI on Feature Branch Tech Blog

テスト工程におけるAI活用

Thu, 18 Jun 2026 00:00:00 +0900

1. はじめに

テスト項目の作成では、Jira、仕様書、ソースコードを見ながら「何を、どの条件で、どう確認するか」を具体化します。

この作業に、最初からAIを使っています。ただし、Codexへ直接依頼し続けるとコンテキストを多く使い、5時間単位や1週間単位の利用制限も気になります。

そこで、まずChatGPTで依頼文を整理し、その内容をCodexに渡してテスト項目のたたき台を作っています。

2. テスト工程をざっくり整理

テスト工程は、確認する範囲で分けると理解しやすいです。 ISTQBでも、テストレベルは目的や責任範囲に応じて整理されています¹。

工程	何を見るか	担当イメージ
単体テスト	関数、入力チェック、画面部品など	実装者が中心
結合テスト	画面、API、DB、権限などのつながり	テストチームが中心
総合テスト	利用者の業務フロー全体	テストチームが中心

今回の主役は、結合テストです。

結合テストでは、単体では問題なさそうに見える部品を組み合わせたときに、正しく動くかを確認します。たとえば、画面で入力した内容が保存されるか、権限ごとに表示が変わるか、同時操作でデータが壊れないか、といった観点です。

3. 今回のテストチームの役割

今回のプロジェクトでは、役割を次のように分けています。

担当	主な作業
各実装者	単体テストを実施
テストチーム	結合テスト、総合テストを実施
テストチーム	パターンが多い単体テストも一部対応

テスト項目を作る材料は、主に以下です。

Jira
仕様書
ソースコード
操作マニュアル
既存のテスト項目

テスト項目では、「動作確認する」だけでは足りません。実施者が迷わないように、操作者、前提条件、操作手順、期待結果まで書く必要があります。

4. AIを使ったテスト項目作成の流れ

実際の流れはシンプルです。

手順	やること	担当
1	実装内容と確認したい観点をざっくり書く	人間
2	ChatGPTでCodex向けの依頼文に整える	ChatGPT
3	Jira、仕様書、ソースコードを見て項目を作る	Codex
4	内容を確認し、実施できる形に直す	人間

ChatGPTを挟む理由は、Codexを節約したいからです。

Codexにはソースコードを読んでほしいので、雑な相談や依頼文の整理でコンテキストを消費するのはもったいないです。そのため、ChatGPTで「Codexに何を頼むか」を先に固めます。

依頼文で指定する内容は、だいたいこのあたりです。

指定すること	例
参照元	Jira、仕様書、関連ソースコード
出力形式	Markdown表、CSVなど
試験分類	IT、ST
観点	正常系、異常系、権限、境界値、既存影響
追加情報	想定工数、不明点、確認が必要な点

OpenAIのプロンプトガイドでも、役割や必要な情報を明確にすることが有効だとされています²。テスト項目作成でも、依頼が具体的なほど出力が安定します。

Claudeのアーティファクト入門〜暮らしを助ける小さな道具を作ってみよう〜

Wed, 27 May 2026 12:00:00 +0900

はじめに

「自分にちょうどいい、シンプルな自己管理アプリがあったらいいのに」——そう思ったことはありませんか。続けたい習慣をチェックするだけのトラッカー、自分の支出項目に合わせた家計メモ、読んだ本を記録するリスト。市販のアプリは多機能すぎたり、逆に欲しい項目が足りなかったりで、なかなか“ちょうどいい一品”には出会えないものです。

そんな“自分好みの小さな道具”を、プログラミングなしで作れてしまうのがClaudeの「アーティファクト（Artifacts）」です。Claudeが作ったものを会話の隣の専用パネルに表示し、その場で見て・触って・共有できる機能で、ちょっとしたアイデアを「日常生活を助ける小さな道具」に変えるのが得意です。

そもそもアーティファクトとは何か
Anthropicがなぜこの機能を作ったのか（思想）
できること・できないこと（2026年時点の最新仕様）
日常生活で役立つ作例

1. そもそもアーティファクトって何？

1.1 一言でいうと

アーティファクト（Artifacts）は、Claudeが作ったものを、会話の隣の専用パネルに表示して、その場で見て・触って・編集できる機能です¹。

文章・コード・Webページ・図・小さなアプリなどを、チャットの流れに埋もれさせず、独立した「作業スペース」として扱えるのがポイントです。

1.2 身近な比喩で

イメージとしては、チャット相手が目の前で小さな道具をこしらえてくれる「作業台」のようなものです。

ふつうのチャットは、口頭で相談しているだけの状態
アーティファクトは、相談しながら隣の作業台で実物を組み立て、その場で動かして見せてくれる状態

「おしゃべり」が「ものづくり」に変わる、と考えると分かりやすいです。

1.3 どんなものが作れる？

作れるものは多岐にわたります。代表的なものは次の通りです¹。

種類	具体例
ドキュメント	Markdown・プレーンテキストの文章
コード	各種言語のスクリプトやコード片
Webページ	1枚もののHTML（CSS・JavaScript入り）
Reactコンポーネント	状態を持つインタラクティブなUI部品
図・ダイアグラム	フローチャート、シーケンス図など（Mermaid）
画像	SVGベクター画像
ダウンロード資料	`.docx` / `.pptx` / `.xlsx` / `.pdf`

1.4 いつからある機能？

意外と歴史は浅く、2024年に登場してから猛烈な勢いで進化してきました。主な歩みは以下の通りです。

時期	アップデート内容
2024年6月20日	プレビュー公開（Claude 3.5 Sonnetと同時に登場）²
2024年7月初旬	公開URL（claude.site）への公開と、他人の作品をコピーして使う remix を追加
2024年8月26日	全プラン（無料含む）で一般公開
2025年6月25日	AIを埋め込んだアプリを作れる機能をベータ公開³
2025年7月31日	PDF・画像・ファイルのアップロードに対応³
2025年10月21日	外部サービス連携（MCP）と永続ストレージ（20MB）に対応³
2026年4月	Live Artifacts（開くたびに最新データへ自動更新するダッシュボード）登場

2. なぜAnthropicはこれを作ったの？（思想）

機能の「何ができるか」だけでなく「なぜ作ったのか」を知ると、使いどころの勘が働くようになります。

AIと和解する

Thu, 02 Apr 2026 00:00:00 +0900

AIと和解する

はじめに

AIとはなんぞや？AIにコーディングさせても効率落ちるのでは？という印象をもっていた古いエンジニアが、AIと仲良く仕事できるようになっていく過程で感じたことや今後AIと仕事をしていくうえで何を気にしながらやり取りしていこうとしているかを共有したいと思います。

1. 怪訝期〜こいつ何者？〜

こちらが実現したいことを伝えても期待通りには捉えてくれないんでしょう？
AIに任せても手直しが必要になって、余計に時間がかかるんでしょう？
実装はできたとしてもスパゲッティコードになって解読に苦労するんでしょう？
ドキュメントを作らせても正確でなく読みづらい文章になるんでしょう？
依頼するにも何を任せていいのかがわからない

2. 受入期〜ちょっと抜けてるけどいい仕事する〜

あいまいな質問をしても答えてくれるし、自分でWeb検索して探すより情報収集が早い
設計の相談をすると自分が気付いていなかった視点で方式を提案してくれる
設計変更やバグ等で現状分析すると、自分で調べるよりはるかに早く分かりやすい結果を返してくれる
実装してもらうと不要なコードが残ったり書き方が分かりづらい部分があるなぁ

3. 和解期〜何をお願いしてもこなしてくれる〜

関連する複数ファイルを変更しなればならない場合も人が書くより全然速いし的確
あいまいな方針から壁打ちで具体化していき細部まで決まれば実装が正確
面倒なテストケースの作成もまとめて実施してくれるしアサーションも意味あるものになっている
やたらと処理を細分化しようとするけどそれが標準だよなぁ

4. 信頼期〜適切な指示で後はお任せ〜

スタートさえ間違わなければ実装はほぼ任せてしまえる
成果物のチェックは、一通り行うがざっくりと違和感を探す程度
全て依存するのではなく細かいミスは手直しすれば無駄な時間を省ける
0.5~0.6人分くらいの作業はAIでこなせる

5. 信頼はしているけれど…

設計・実装ではインプットを曖昧にしない
- 最初のインプットを曖昧にしても壁打ちを繰り返すことで求める結果に辿り着くかもしれないが作業短縮効果が薄れる
- 具体化できている部分をその通りに伝えることでより正確な分析をしてくれるので、結果も速く正確になる
成果物イメージを持つことをサボらない
- 自分の中で成果物のイメージがあると、想定と違う≒間違いを検出できる
- AIの間違いでなくとも、自分の間違いに対してその対応で問題ないかのチェックができる
自分が分からないことを任せない
- 成果物が正しいのか判断できなければ成果物として成り立たない
- 分からないなら分かるまで壁打ちしたから目的の成果物作成を任せる

6. ただ裏では

ここまでAIを信頼できる状態になっているのは、単にAIの進化だけが要因ではない。裏で有識者がAGENTS.mdの調整や適切なSkillsの導入をしていることも大きな要因になっている。なので、単に使い方を工夫するだけでは足りず、AGENTS.mdの書き方やSkillsに対する知識も付ける必要がある。

7. まとめ

AIは日々進化しており信頼できる相棒足りえる
現状分析・コーディングレベルの作業はAIの生産性には勝てない
人に必要な能力
- 成果物を明確にイメージして具体的にAIへ伝える
- アウトプットと成果物イメージに差異がないか見極める
- AIの基本設定を行える

昔は曖昧だと止まった。今は曖昧でも進む。だからAI時代の方が危ない

Sun, 29 Mar 2026 09:00:00 +0900

昔は曖昧だと止まった。今は曖昧でも進む。だからAI時代の方が危ない

はじめに

AIを使うと、仕事が前に進む速度は確かに上がります。

コードのたたき台を作る。文章を整理する。調査の出発点を作る。ひと昔前なら半日かかったことが、数分で返ってくることもあります。

そこは本当に便利です。

でも、その便利さの裏に少し怖さがあります。

昔、ある自動車メーカー向けのCAD関連の仕事で、車体がたわんだときに、ある部品の曲面が別の部品にどう影響するかを計算する処理を作ったことがありました。

CGっぽく言うと、あるボディパネルの影が別のパネルのどこに落ちるか、みたいな計算です。担当の数学者が提示した式を、私がコンピュータで動く形に落とし込んでいました。

ところが、どうしても収束しないケースが出ました。

当然、最初は自分の実装ミスを疑いました。でも調べていくと、実装ではなく、渡されていた計算式のほうに問題があったんです。修正案とエビデンスをそろえて担当数学者に確認し、最終的に必要な機能を満たす形に直しました。

CGなら、ある程度それっぽく見えれば許される場面もあるかもしれません。でも、自動車の部品ではそうはいきません。人を乗せて走るものだからです。

この件を振り返って今強く思うのは、昔の開発は、曖昧さや不具合があると途中で止まるしかなかった、ということです。

人が確認に入る。検証で矛盾が見つかる。計算が収束しない。つまり、曖昧さが早い段階で露出しやすかった。

ところが今は、AIがそこをそれっぽく埋めて前へ進めてしまいます。止まらない。速い。しかも、見た目もそれなりに整っている。

だから私は、AI時代は楽になった部分もある一方で、仕様を伝える難しさはむしろ上がったと思っています。

1. 昔は、曖昧さがあると止まった

昔の開発環境は、今のように気軽ではありませんでした。

計算資源が限られていた
実行確認の回数も少なかった
一回の手戻りが重かった

そんな環境では、「まあ、だいたいこういう意味だろう」で進めるのは危険でした。

数学者や物理学者が考えた内容を、そのまま機械が理解してくれるわけではありません。考え方を整理し、前提を確認し、条件を明文化し、コンピュータが処理できる形に落とし込む必要がありました。

たとえば、次のような点が曖昧なままだと、どこかで必ず詰まります。

何を求めたいのか
どこまでの誤差を許すのか
想定外の入力が来たらどうするのか
何をもって正しいと判断するのか

昔は、こういう曖昧さがあるとごまかしが利きませんでした。

計算結果が合わない。検証で再現しない。レビューで説明できない。曖昧な部分が、そのまま手戻りや停止として返ってきたのです。

しかも重要なのは、通訳する側が単に受け取って流すだけでは足りなかったことです。成立しているか、破綻しないか、要求を満たすかまで見ないと仕事になりませんでした。

今振り返ると、あの時代に必要だったのは「賢い人の頭の中にあるものを、曖昧さの少ない仕事の言葉に変えること」であり、同時に「それが本当に成り立つかを検証すること」でもありました。

2. 今は、曖昧でも進んでしまう

今はそこにAIが加わりました。

AIは便利です。ですが、読心術は使えません。

こちらが言っていない前提は、本来分からないはずです。それでもAIは、足りない部分を推測して、それっぽく補い、もっともらしい答えを返します。

たとえば、こう頼んだとします。

1

この画面のバグを直して

これでもAIは何かしら返してきます。

でも、本当に必要な情報はかなり抜けています。

どの画面か
何がバグなのか
期待する挙動は何か
触ってよい範囲はどこまでか
何を確認したら完了なのか

人間の実装者なら、「情報が足りません」と聞き返してくれるかもしれません。ところがAIは、そこを自分で埋めて進みがちです。

ここが便利さであり、同時に危なさでもあります。

昔は曖昧だと止まりました。
今は曖昧でも進みます。

進むこと自体は良いのですが、正しい方向に進んでいるとは限りません。

しかもAIは速いので、ズレた前提のまま成果物が量産されやすい。これが人間相手より厄介だと感じる理由です。

3. 危ないのは「間違うこと」より「間違ったまま進むこと」

人間もAIも間違えます。そこ自体は新しい話ではありません。

でもAI時代に少し怖いのは、間違いが露出しにくいことです。

コンパイルエラーのように止まってくれれば気づけます。レビューで「この前提は違います」と返ってくれば立て直せます。

ところがAIは、ある程度もっともらしい文章、コード、設計案を返してきます。見た目が整っているので、「とりあえず前に進んだ感」が出てしまう。

私は、ここにAI時代の落とし穴があると思っています。

危ないのは、AIが間違うことそのものではありません。曖昧な依頼でも、止まらず、確認もせず、もっともらしく前へ進んでしまうことです。

昔の不便な環境には、皮肉にも安全装置がありました。曖昧さや不具合があると、収束しない、説明できない、検証で落ちるといった形で止まりやすかったからです。

今は便利になったぶん、その安全装置が弱くなったとも言えます。

4. では、何が必要なのか

ここで必要になるのは、魔法のようなプロンプトではないと思っています。

必要なのは、昔からある基本です。曖昧な仕事を、相手に渡せる仕様へ変換することです。

仕様駆動開発 — Specsを中心とした開発フロー

Mon, 02 Feb 2026 10:00:00 +0900

はじめに

2025年、**仕様駆動開発（Spec-Driven Development）**が話題になり、関連ツールを試してみました。しかし、従来のSDDには「ドキュメント過剰」の課題を感じ、直近の開発で試行錯誤する中での、私なりのアプローチを整理します。

1. 仕様駆動開発の理想と現実

2025年、AIコーディングエージェントの登場により**仕様駆動開発（Spec-Driven Development）**が再注目されています¹。

SDDの理想

SDDの理想では、Specレビュー → 実装 → テスト/検証 → フィードバックのサイクルが日単位で回転し、AIにより爆速化されるはずでした²。

flowchart LR
 A[📝 Spec作成] --> B[🔍 Specレビュー]
 B --> C[💻 AI実装]
 C --> D[✅ テスト/検証]
 D --> E{フィードバック}
 E -->|修正| A
 E -->|OK| F[🎉 リリース]

現実の課題

しかし、実際にSDDを試してみると、いくつかの課題が見えてきました。

課題	説明
Specの巨大化	小さな機能追加でも数千行のSpecが生成され、レビューが重くなる²
正確性検証の難しさ	LLMが確率的な出力をする以上、Specのみで実装漏れやミスを防ぐのは難しい
組織的な調整	エンジニア単独では完結せず、PM・QAなど複数ステークホルダーの関与が必要
小規模開発への不適合	単純なバグ修正に詳細仕様を書くのはオーバーヘッド

開発手法の歴史 — 振り子の揺れ

開発の歴史は、「重すぎる文書化」と「軽すぎる文書化」の間で振り子のように揺れ動いてきました。³

flowchart LR
 subgraph 歴史の振り子
 A[📚 ウォーターフォール
重すぎる文書化] -->|反動| B[🏃 アジャイル
軽すぎる文書化]
 B -->|反動| C[📝 SDD
再び仕様重視?]
 C -->|課題| D[🎯 バランスを探る]
 end

アジャイル開発は「重すぎる文書化」の反動として生まれましたが、別の課題も生まれました。

2ターン設計で精度を上げる：VSCode×Codexのやりとり術

Thu, 22 Jan 2026 10:00:00 +0900

はじめに

「VSCodeからCodexにお願いしたけど、意図とズレた」――そんな経験はありませんか。私自身、短く書くと精度が落ち、長く書くと伝える内容が散らばることがありました。

そこで効果があったのが2ターン設計です。1回目で前提を確認し、2回目で実行に移す。たったそれだけで、精度と納得感が上がりました。この記事では、VSCode×Codexで使える「2ターンの型」を整理します。

1. なぜ1回でうまくいかないのか

LLMは文脈が不足していると、良い推測はしても本当に欲しい答えに辿り着けないことがあります。公式のプロンプト指針でも「目的・制約・期待する出力」を明確に伝えることが推奨されています¹²。

つまり、1回目の指示で「必要な前提が足りているか」を確かめるだけで、2回目の成功率が大きく上がります。

2. 2ターン設計の全体像

2ターン設計は、**確認（Turn 1）→実行（Turn 2）**の流れです。会話の段階を明確にするだけで、やりとりが安定します。

flowchart LR
 A[Turn 1: 調査・前提確認] --> B[Turn 2: 実装・反映]

Turn 1: 調査・前提確認

このターンでは、**「何を、どこまで、どういう形で」**を固めます。足りない情報があれば質問してもらい、必要な前提を揃えるのが目的です。質問してから進めるスタイルは公式例でも推奨されています³。

Turn 2: 実装・反映

Turn 1で前提が揃ったら、実装・修正・整理などを依頼します。ここでは作業のゴールと受け入れ条件が明確になっていることが大事です。

3. Turn 1のテンプレ（そのまま使える）

短くてもよいので、次の項目を伝えると迷いが減ります。

目的
変更範囲
期待する出力
制約（触らない場所、守るルール）
参照してほしいファイル

実際のテンプレはこんな感じです。

1
2
3
4
5
6
7


目的: 画面の表示崩れを直したい
変更範囲: @src/pages/order-detail/ だけ
期待出力: レイアウトが崩れずに表示されること
制約: UIの文言は変更しない
参照: @src/pages/order-detail/index.tsx

まず原因を調査して、必要なら質問してください。

ポイントは「まず調査して」と先にフェーズを指定することです。これだけで、いきなり修正を始めるリスクが減ります。

4. Turn 2のテンプレ（承認してから実行）

Turn 2では「OK、やってください」を明示します。明確な実行依頼が推奨されることは公式のベストプラクティスでも触れられています¹²。

1
2
3
4
5


ありがとうございます。修正案で進めてください。

- 変更は最小限で
- テストは不要
- 差分を最後にまとめてください

この形式だと、実装範囲が安定し、仕上がりの確認も楽になります。

【実践】AIエージェントでのコーディング指南書 - 4ヶ月の開発から学ぶプロンプト術

Wed, 07 Jan 2026 10:00:00 +0900

はじめに

「AIエージェントを使ってみたけど、うまく動かない」「何を指示すればいいかわからない」——そんな声をよく聞きます。

この記事は、約4ヶ月間AIエージェント（Claude Code、Codex CLIなど）を使って開発してきた経験から見つけた、効果的なパターンをまとめた指南書です。これまで各自が試行錯誤しながら使ってきましたが、知見が整理されないまま属人化していました。開発チームに新メンバーが加わったこのタイミングで、改めてノウハウを整理・共有することにしました。

1. 効果的なプロンプトの書き方

1.1 「@ファイルパス」でコンテキストを明示する

AIエージェントは賢いですが、読心術は使えません。どのファイルの話をしているのか、明示的に教えてあげましょう。

1
2
3
4
5
6
7


❌ 悪い例：
「このエラーを直して」

✅ 良い例：
「@src/components/user-profile/sections/department-info.tsx
について、部署名がIDのまま表示されてしまっています。
原因を調査して修正してください。」

Anthropic のベストプラクティスでも、「giving clear directions upfront reduces the need for course corrections later」（最初に明確な指示を与えることで、後から軌道修正する必要が減る）と述べられています¹。

@記法のポイント：

ポイント	良い例	悪い例
フルパスで指定	`@src/components/.../file.tsx`	`file.tsx を見て`（どこにあるか不明）
複数ファイル比較時	両方のパスを明示	「もう一つのファイルと比較して」

1.2 問題の背景・文脈を詳細に説明する

実際の開発で効果的だったプロンプトパターンを見てみましょう。

1
2
3
4
5
6
7


元請けベンダーから以下の質問が来ています。
コードベースやSalesforceの現在のライセンス構成での
ガバナ制限など、Context7やネット調査も含めて調査してください。

---

[質問内容をそのまま貼り付け]

このプロンプトには以下の要素が含まれています。

頭脳 vs 手足：Claude Code（Opus 4.5）とCodex CLI（GPT-5.2）徹底比較

Tue, 06 Jan 2026 12:00:00 +0900

はじめに

2025年末から2026年にかけて、AIコーディングツールは新たなステージに突入しました。AnthropicのClaude Code（Opus 4.5）とOpenAIのCodex CLI（GPT-5.2）は、どちらも「AIエージェントが自律的にコードを書く」時代を切り開いています。

しかし、この2つのツールは設計思想が根本的に異なります。本記事では、**「頭脳 vs 手足」**という独自の視点からこの2大ツールを比較し、それぞれの強みと使い分けのポイントを解説します。

1. 両ツールの概要

まずは、それぞれのツールの基本的な特徴を押さえておきましょう。

1.1 Claude Code + Opus 4.5

Claude Codeは、Anthropicが提供するAIコーディングエージェントです。2025年11月にリリースされたOpus 4.5モデルと組み合わせることで、「世界最高のAIコーディングツール」を謳っています¹。

主な特徴は以下の通りです。

ローカルファースト設計: ターミナルやIDEに直接統合され、開発者のワークフローに溶け込む
インタラクティブな操作: 開発者が「コントロールを握り続ける」設計思想
チェックポイント機能: 作業の進捗を保存し、いつでも以前の状態にロールバック可能
ハイブリッド推論: 即座の応答と拡張思考を状況に応じて切り替え

1.2 Codex CLI + GPT-5.2

Codex CLIは、OpenAIが提供するオープンソースのAIコーディングエージェントです。GPT-5.2-Codexは、複雑なソフトウェアエンジニアリングタスクに最適化された専用モデルで、2025年12月にリリースされました²。

主な特徴は以下の通りです。

クラウドベース設計: タスクは隔離されたサンドボックス環境で非同期に処理
委任型ワークフロー: タスクを渡して「任せる」スタイル
長時間自律作業: テスト中に7時間以上連続して複雑なタスクに取り組んだ実績
サイバーセキュリティ強化: CTFチャレンジでの高精度を実証

2. 「頭脳 vs 手足」の比較軸

ここで本記事の核心となる比較軸を紹介します。

観点	GPT-5.2 Codex（頭脳型）	Claude Code + Opus 4.5（手足型）
設計思想	「深く考える」ことに最適化	「精密に実行する」ことに最適化
強み	巨大なコンテキスト、長時間思考	ローカル統合、ツール操作の精度
操作感	「従業員に任せる」感覚	「道具を使いこなす」感覚

2.1 GPT-5.2 Codex：「賢い頭脳」

GPT-5.2 Codexは、まさに**「頭脳派」**のAIエージェントです。

GPTとChatGPT入門（発表用スピーカーノート）

Wed, 17 Dec 2025 00:00:00 +0900

GPTとChatGPT入門

発表時に話すためのスピーカーノート

※このファイルは スライドに書く文章ではなく、発表時に話す内容 です。

概要

今日は、GPTとChatGPTについて
できるだけ 専門用語を使わずに、イメージしやすく説明します。

GPTは、人間のように理解して考えているAIに見えるかもしれませんが、
実際には 文章の流れから、次に来そうな言葉を予測して文章を作る仕組み です。

この発表では、

GPTとは何か
ChatGPTとの違い
そして日常や仕事でどう使えるか

この3点を押さえていきます。

1. GPTとは何か

まず、GPTという名前の意味からです。

GPTは
Generative Pre-trained Transformer の略です。

Generative（生成）
新しい文章を作り出せる、という意味です。
Pre-trained（事前学習済み）
あらかじめ大量の文章を読んで、知識を身につけている、という意味です。
Transformer
言葉と言葉の関係を理解するためのAIの仕組みです。

つまりGPTは、
たくさんの文章で事前に学習したうえで、
新しい文章を作り出せるAIだと考えてください。

2. GPTは実際に何をしているか

次に、GPTが実際に何をしているかです。

やっていることは、とてもシンプルです。

「この文章の流れなら、次にどんな言葉が来そうか？」
これを ひたすら予測し続けている だけです。

スマートフォンの予測変換が、
とても賢くなったものを想像すると分かりやすいと思います。

GPTは、人間のように意味を理解して考えているわけではなく、
文章を自然につなげている だけです。

3. GPTの得意なこと・苦手なこと

GPTには、はっきりとした得意・不得意があります。

得意なことは、
長い文章の要約、翻訳や言い換え、
説明文やメールの作成、アイデア出し、
プログラミングの補助などです。

一方で苦手なことは、
事実の正確性を保証すること、
最新の情報を把握すること、
あいまいな指示を正しく理解することです。

そのためGPTは、
答えを決める存在ではなく、人を助ける道具 として使うのが重要です。

4. GPTとChatGPTの違い

GPTとChatGPTは、名前が似ているのでよく混同されますが、役割が違います。

GPTは、文章を生成する 中身の技術 です。
ChatGPTは、そのGPTを 誰でも使いやすくしたアプリケーション です。

【2025年版】エンジニア向けAI用語整理ガイド

Mon, 01 Dec 2025 00:00:00 +0900

はじめに

最近のIT開発では「AI」「LLM」「エージェント」といった言葉が飛び交っています。この記事では、これらの用語をざっくり整理してみます。

そもそもAIとは？

AI（Artificial Intelligence / 人工知能） とは、人間の知的な振る舞いをコンピュータで再現しようとする技術の総称です。

具体的には以下のような能力があります。

画像認識（写真に何が写っているか判定）
音声認識（話し言葉をテキストに変換）
自然言語処理（テキストの意味を理解・生成）
推論・判断（データから予測や意思決定）

ポイント: AIは非常に広い概念で、チェスを打つプログラムも、ChatGPTも、自動運転も、すべて「AI」です。

LLMとは？

LLM（Large Language Model / 大規模言語モデル） とは、膨大なテキストデータを学習し、人間のような文章を理解・生成できるAIのことです。

代表的なものは以下です（2025年12月時点）。

GPT-5 / o3（OpenAI）
Claude Opus 4.5 / Sonnet 4.5（Anthropic）
Gemini 3（Google）
Llama 4（Meta）

モデルとは？

「モデル」とは、学習済みのAIの「頭脳」部分のことです。

学習データ（インターネット上の大量のテキスト）を使って
パターンを学習し
出力（回答や文章）を生成できる状態になったもの

同じLLM製品でも、複数のモデルが提供されています。

Claude: Haiku 4.5（軽量・高速）、Sonnet 4.5（バランス型）、Opus 4.5（高性能）
GPT: GPT-5 Mini（軽量）、GPT-5（標準）、o3（推論特化）
Gemini: Flash（高速）、Pro（標準）、Deepthink（推論特化）

モデルの性能は重要

「とりあえず動けばいいや」ではなく、適切なモデル選択が重要です。

理由は次の通りです。

回答の正確性 - 高性能モデルほど複雑な質問に正確に答えられる
コード生成の品質 - バグの少ない、保守しやすいコードを生成
指示の理解力 - 曖昧な指示でも意図を汲み取れる
コストとのバランス - 単純なタスクには軽量モデル、複雑なタスクには高性能モデルを使い分ける

AI on Feature Branch Tech Blog

テスト工程におけるAI活用

1. はじめに

2. テスト工程をざっくり整理

3. 今回のテストチームの役割

4. AIを使ったテスト項目作成の流れ

Claudeのアーティファクト入門 〜暮らしを助ける小さな道具を作ってみよう〜

はじめに

1. そもそもアーティファクトって何？

1.1 一言でいうと

1.2 身近な比喩で

1.3 どんなものが作れる？

1.4 いつからある機能？

2. なぜAnthropicはこれを作ったの？（思想）

AIと和解する

AIと和解する

はじめに

1. 怪訝期 〜こいつ何者？〜

2. 受入期 〜ちょっと抜けてるけどいい仕事する〜

3. 和解期 〜何をお願いしてもこなしてくれる〜

4. 信頼期 〜適切な指示で後はお任せ〜

5. 信頼はしているけれど…

6. ただ裏では

7. まとめ

昔は曖昧だと止まった。今は曖昧でも進む。だからAI時代の方が危ない

昔は曖昧だと止まった。今は曖昧でも進む。だからAI時代の方が危ない

はじめに

1. 昔は、曖昧さがあると止まった

2. 今は、曖昧でも進んでしまう

3. 危ないのは「間違うこと」より「間違ったまま進むこと」

4. では、何が必要なのか

仕様駆動開発 — Specsを中心とした開発フロー

はじめに

1. 仕様駆動開発の理想と現実

SDDの理想

現実の課題

開発手法の歴史 — 振り子の揺れ

2ターン設計で精度を上げる：VSCode×Codexのやりとり術

はじめに

1. なぜ1回でうまくいかないのか

2. 2ターン設計の全体像

Turn 1: 調査・前提確認

Turn 2: 実装・反映

3. Turn 1のテンプレ（そのまま使える）

4. Turn 2のテンプレ（承認してから実行）

【実践】AIエージェントでのコーディング指南書 - 4ヶ月の開発から学ぶプロンプト術

はじめに

1. 効果的なプロンプトの書き方

1.1 「@ファイルパス」でコンテキストを明示する

1.2 問題の背景・文脈を詳細に説明する

頭脳 vs 手足：Claude Code（Opus 4.5）とCodex CLI（GPT-5.2）徹底比較

はじめに

1. 両ツールの概要

1.1 Claude Code + Opus 4.5

1.2 Codex CLI + GPT-5.2

2. 「頭脳 vs 手足」の比較軸

2.1 GPT-5.2 Codex：「賢い頭脳」

GPTとChatGPT入門（発表用スピーカーノート）

GPTとChatGPT入門

発表時に話すためのスピーカーノート

概要

1. GPTとは何か

2. GPTは実際に何をしているか

3. GPTの得意なこと・苦手なこと

4. GPTとChatGPTの違い

【2025年版】エンジニア向けAI用語整理ガイド

はじめに

そもそもAIとは？

LLMとは？

モデルとは？

モデルの性能は重要

Claudeのアーティファクト入門〜暮らしを助ける小さな道具を作ってみよう〜

1. 怪訝期〜こいつ何者？〜

2. 受入期〜ちょっと抜けてるけどいい仕事する〜

3. 和解期〜何をお願いしてもこなしてくれる〜

4. 信頼期〜適切な指示で後はお任せ〜