生成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. では、何が必要なのか

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

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

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. では、何が必要なのか

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

GPTとChatGPT入門

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

概要

1. GPTとは何か

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

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

4. GPTとChatGPTの違い

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

はじめに

そもそもAIとは？

LLMとは？

モデルとは？

モデルの性能は重要

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

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

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

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

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