キャッチ。 伊藤さん、バトンを受け取りました。 冷房の効いた室内と近年とりわけ気候変動によって過熱している屋外とで、寒暖差の激しい日々が続いておりますが、いかがお過ごしでしょうか。 ノーコードテストツールのバトンは画鋲付きで渡した気分でした。 しかし、誠実に答えてくださり、ありがとうございました。 テスト自動化は運用が大切、というのは私自身、伊藤さんから繰り返し学んでいたことでしたね。 そして、ノーコードかコードベースかといった軸とは全く違うパラダイムの進化というのは大変示唆的です。 そもそも生成AIの多くは、LLMにチャットというインターフェースを使って接続するものです。チャットを組み込んだことはLLMにおける大きなUXの発明です。 しかし、これは今では当たり前になり、誰もそのことを意識しないようになってしまいました。これもパラダイムの進化だと思っています。 それでは、受け取ったバトンを見てみます。 非常に鋭く、かつ本質的な問いがありますね。 伊藤さんからいただいた「テスト自動化は本当に『当たり前』になったのか」「なぜ冷静な視点が必要なのか」という2つの問いについて、私の視点からお答えしつつ、これからの自動テストが向かうべき新たなパラダイムについて考えてみたいと思います。 「当たり前」の現在地 伊藤さんからの最初の問いである「幅広いコミュニティから見て、テスト自動化は本当に当たり前になったのか」について。 私の実感としても、テスト自動化が前提の技術として扱われる機会は確実に増えていると感じます。 プログラミングやアジャイルの文脈を問わず、様々なカンファレンスで自動テストに関するセッションはありますし、「今だからこそ、確かなテストや品質保証が大事である」という共通認識は、かつてないほど高まっていると感じます。 そういった背景もあって、私が「QAエンジニア」あるいは「テスター」という肩書きのまま、受け入れられているという側面があります。 こういった、テストの専門性を受け入れるような”暖かい”雰囲気がある一方、冷静に見極めなければならない「ズレ」があるとも考えます。 世間で当たり前になりつつあるのは、あくまで「どうテスト実行を自動化するのか」に留まっているケースが多いのではないか、ということです。 プロダクトの特性やコンテキストを分析し、合理的なテスト計画と設計に基づき、真に必要な活動を「自動テスト」として成熟しているかというと、そこにはまだ大きな隔たりがあるという肌感覚があります。 (これに対しては、いわゆる”テストエンジニア”による歩み寄りが必要で、その歩み寄り方自体についてもきちんと向き合って考えるべきことだと個人的に思っていますが、ここでは深入りしません) 伊藤さんが指摘された「生成AIという次のブームに押し出されて、自動化の流行りが落ち着いた（ように見える）」という視点は的を射ていると感じます。 これは私自身にも言えることですが、私たちは「知ったつもり」になるのをやめ、その当たり前の中身を問い直さなければなりません。 なぜ「冷静な視点」が必要なのか 私は手動テストの設計時のような「冷静な視点」が必要だと伝えました。そのまま返ってきましたね。 現在、生成AIの台頭によってプロダクトコードが大量かつ高速に生み出されるようになりました。 これに伴い、現場では「開発スピードに合わせて、テストも急いで大量に作らなければならない」という焦燥感のようなプレッシャーが生まれているように感じることがあります。 他方、プレッシャーとは逆の視点で、「難しいコードを書かなくても実装できるぞ！」という熱を垣間見ることもあります。 以前、テストマネジメントの記事でも述べたことですが、私は「コストや期間の制約を考えれば、テストは極力すべきではない（最小限に抑えるべきである）」というのを基本的なスタンスとしています。 むやみにテストを自動化し、ただコードの量を積み上げることは、それこそ運用の破綻を招くだけだと考えます。 ここで問われているのは、大量生産への追随ではなく、「何をテストすべきで、何をテストしなくてよいのか」を見極める、本質的なテストマネジメントの力に他ならないと考えています。 これはプロダクトコードにおけるプロダクトマネジメントの考え方にも通じるものがあります。 生成AIを発端とする熱狂や過剰な期待にただ熱くなるのではなく、事実に基づいてソフトウェアテストの責任をどう果たすか。 これが私の考える「冷静な視点」です。 生成AIがもたらすリアルな制約 ここで、現状の生成AIを使ったテストの「リアル」についても触れておきます。 今後、テスト自動化の現場は「コードを書く」ことから「プロンプトを書く」ことへとシフトしていく可能性が高いです。実際に、BDD（振る舞い駆動開発）のようなプラクティスも再び注目を集めています。 しかし、現状の生成AIを組み込んだテスト運用には、実行時間の制約や、スケールさせた際の予算的な制約が存在します。 その他、並列処理のための最適化などの自動テスト実行環境を綿密に整備しないかぎり、AIによるテストの量産は現実的な運用に乗せられないというのが2026年7月の私の見解です。 ただし、この予算やリソースの制約をクリアした先、あるいは「価値がある」と計算し切れた先には、全く新しい展望があると考えています。 制約を乗り越えた先にあるgTAAの気候変動 その展望とは、組織が集めたプロファイルや顧客データなどに基づいて、品質特性の質感（代用特性としての確らしさ）、つまり「品質が良さそうだ」と判断する根拠に対する感覚が今とは全く異なったものになることです。 ※この意見はスクラムフェス新潟2026のきょんさん、nacoさん、じゅんぺいさんの以下の発表とその後の対話から、私なりに受け取り、解釈したものです。 そして、自動テストの文脈で言えば、JSTQBのテスト自動化エンジニアシラバスで定義されている「gTAA（汎用テスト自動化アーキテクチャ）におけるテスト生成レイヤー」の構築がより簡単になると考えます。 参考： https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TAE_Version2016.J01.pdf これは、gTAAにおける水平レイヤーそれぞれで生成AIを使ったパイプラインを使用し、例えばテスト生成レイヤーの出力をそのレイヤーの中で検証し、それぞれのレイヤーで確からしく実装まで繋がっていく様子をシームレスに確認できるような、発展した形の汎用テスト自動化アーキテクチャです。 そして、生成AIが当然に用いられるプロダクト開発において、「決定論的に見極められる事実を確認する」という意味でテストが重要視されるでしょう。 ※これは冒頭で話した「今だからこそ、確かなテストや品質保証が大事である」の単なる言い換えでしかありません。 「生成AIを活用する」という目的で作るTAAは、「手動テストをただ単に自動化する」という、かつてのテスト自動化の熱狂と同じ構造を持っているのではないでしょうか。 もちろん、それが学習の途中で辿る道であり、私もその中にいることすらあると思っています。 テストが持つ本質的な役割を理解した上で、それをどう生成AIと統合していくかということが、今後の”冷静な”論点になりうると考えています。 そして、その論点を踏まえた上で、自動テストは新しいパラダイムでの「TAA（テスト自動化アーキテクチャ）」を語る熱量が上昇するのではないか、と考えています。 伊藤さんへのバトン 単にテストを自動化する・コードを生成するという次元を超えて、システムや組織のデータそのものをインプットとした「TAAの再定義」という変化が来ているという私の見通しがあります。 ここで、MagicPodのエヴァンジェリストであり、ISTQB Advanced Level Test Automation Engineerの翻訳者のひとりである伊藤さんに、ぜひ最後のバトンをお渡ししたいです。 生成AIが前提の開発において、自動テストアーキテクチャ（TAA）にはどのような変化があるのでしょうか？ そういった状況の中で、テストエンジニアは、ソフトウェアエンジニアリングの世界にどのような良い影響を与えうると見通されていますか？ 私の上記の見解もまた、冷静ではなかったりしますかね？ ←これには答えなくていいです。 一人の専門家としての見解を、ぜひお聞かせください。 The post 【第3回】E2Eテスト自動化でつなぐ③〜テスト自動化における寒暖差〜｜専門家2人による往復書簡 first appeared on Sqripts .

今年も半分が過ぎました。2026年4-6月のサマリーです。 記事数・執筆者数 # この3ヶ月で13本の記事が投稿され、記事数は889になりました。 連載 # AIエージェントとシステムをつなぐMCP入門 # MCP(Model Context Protocol) は AI エージェントが外部サービスと通信するための仕様で、2024年に Anthropic 社によって初版がリリースされました。MCP を使用することで、AI エージェントは外部サービスの機能を効果的に利用できます。MCP の基本から実装まで段階を分けて解説するシリーズです。 /blogs/2026/04/24/mcp-impl_introduction/ 現在は以下の6記事が公開されています。 イントロダクション stdio実装編 StreamableHTTPステートレス実装編 StreamableHTTPステートフル実装編 プロンプト編 リソース編 テーマ別記事 # 認定資格 # /blogs/2026/04/13/google_cloud_all_certified_revenge/ /blogs/2026/04/20/aws_certified_generative_ai_developer/ ペアレンタルコントロール # 上記の AWS・Google Cloud 認定を“W全冠”したエンジニアが、クラウドから降りて自宅のネットワークと格闘した異色の記事です。夜中に学校用タブレットでゲームをする子供との「イタチごっこ」に終止符を打つべく、手持ちの家庭用ルータとRaspberry Piを活用して、MACアドレス制限やサブネット分離、Pi-holeによる独自DNS構築まで、本気の「ガチ構成」を徹夜で組み上げる様子を赤裸々に綴っています。DoH（暗号化DNS）対策などのリアルな課題にも触れられており、ネットワークの基礎を学び直したい方や、同じ悩みを持つITエンジニアの親御さん必見の泥臭くも愛に溢れた実践録です。 /blogs/2026/04/09/home_network_control/ スクラムマスターと AI # チームの対話を支えるスクラムマスターにとって、視覚的な資料作成は欠かせませんが、一方で多大な時間がかかるのが共通の悩み。本記事では、そのボトルネックを AI で突破する実践的な手法を解説しています。ChatGPT を思考のパートナーとして構成を練り上げ、最新の生成 AI ツールでスライドを一気に形にする――単なる「時短術」に留まらず、AI との対話を通じてアイデアを磨き、本来注力すべきファシリテーションやコーチングの質を高めるための「共創のプロセス」を紹介しています。資料作成の重圧から解放され、チームの価値最大化に向き合いたいリーダー・マネージャーにとっても役立つ内容となっています。 /blogs/2026/04/27/ai-presentation/ GitHub # GitHub の Organization 運用において、「機密リポジトリを作りたいが、Basic Permission の設定変更による管理コスト爆発は避けたい」というジレンマ。この記事では、高価なEnterprise プランを契約せずとも、Teams プランの制限下で安全かつ効率的にアクセス権を管理する「ホワイトリスト方式」の戦略を解説しています。全メンバー用の統合チーム作成によるセキュリティ境界の構築から、GitHub API と Actions を組み合わせた「チーム追加漏れを防ぐ自動化スクリプト」の実装まで、管理者の負担を増やさない現場目線のハックを紹介しています。 /blogs/2026/06/24/github-manage-organization-access/ CI/CD 環境で広く使われる GitHub Actions に新たに追加された、単一ワークフロー内でのステップ並行実行機能をいち早く検証した記事です。background 属性を使った非同期実行や、parallel ブロックを使った同時実行の基本構文を解説するだけでなく、Go 言語のクロスコンパイルを用いた実践的なパフォーマンス検証も実施。vCPU コア数やコンテキストスイッチの観点から「期待したほど速くならなかった理由」と、「これまでの Matrix ビルドとどう使い分けるべきか」まで深く考察しており、現場の CI 改善に直結する生きた知見が得られます。はてなブックマークでも注目され、公開直後からアクセスが上昇しました。 /blogs/2026/06/27/github-actions-parallel-steps/ さいごに # 以上、2026年度第1四半期のサマリーでした。投稿数が少なかったため、個別の記事紹介を厚めにしてみました。 よかったら フィード の購読、 X や Bluesky でのフォローもお願いします。 Facebook でも本サイトの注目記事をはじめ豆蔵に関するイベントを紹介しています。 note にも時々本サイト関連の記事が掲載されています。

開発2部の内原です。 AIエージェントを使って開発していると、同じモデルを使っているはずなのにツールやエージェントによって賢さがまるで違う、という体験をすることがよくあります。モデルそのものは変わらなくても差が出る理由を考えてみます。 その差を生んでいるのが、モデルを取り巻く装備、いわゆるハーネスです。ハーネスという言葉はなんとなく使われがちですが、何を指しているのかは意外とふわっとしています（少なくとも自分の理解は割と曖昧でした）。 この記事では、この言葉を構成要素に分解して、何がエージェントの実力を決めているのかを整理してみます。 エブリーにおけるAIエージェントの活用状況とハーネスの必要性 先日の 村上からの投稿 全社のAIファーストを牽引するエンジニアの役割 でも言及がありましたが、エブリーでは今年から全社的にClaudeの活用を進めてきました。 それ以前からも特に開発部においてはCopilotやCursorなどのAIエージェントが利用されていましたが、当初は主にコーディング用途に使われていました。それが、開発部に閉じない業務改善、業務遂行のためにAIが用いられるようになってくると、エンジニアの役割も単なる実装者から、よりプロダクトや業務の理解を求められるようになり、業務フロー全体を考慮したオーケストレーションを実施する必要がでてきました。 その中で、より自律的なAI活用のためにはハーネスが重要になってくると考えています。AIに対しどのように振る舞うべきかを伝える必要があるためです。 なお、ハーネスの考え方自体はあらゆるAIエージェントに共通しますが、本記事では話を具体的にするため、特に開発で使うコーディングエージェントを念頭に置いて進めます。 モデル単体とハーネスの違い まずLLM単体は何をするものなのかを考えます。LLMは、突き詰めれば入力テキストに対して出力テキストを返すだけの関数であると言えます。それ自体ではファイルを読むことも、コマンドを実行することも、前回の作業を覚えていることすらできません。 一方実用的なAIエージェントは、そのモデルの周りに情報を渡す仕組みや道具、結果を確かめる仕組みを組み合わせ、それらを繰り返し動かしています。この一式をまとめてハーネスと呼びます。本記事では、ハーネスについてモデルを実世界におけるタスクに接続するための装備一式であると定義します。 ハーネスという言葉は、もともとは犬や馬のような対象に取り付けてその力を御し、目的の方向へ引き出すための装具を指します。ソフトウェアにおいても意味合いは同じく、テスト対象を動かすためのテストハーネス（スタブ、ドライバなど）のように、中心にある対象を制御して動かすための周辺の仕組みを指してきました。 AIエージェントのハーネスも同じで、モデルそのものではなく、その力を制御して実世界のタスクに向かわせるための装備だと捉えると分かりやすいです。 ハーネスを構成する4つの要素 ハーネスを、コンテキスト、ツール、権限・実行環境、検証ループの4つの要素に分けて見ていきます。 ただこれらの分類は絶対的なものではなく、目的や環境に応じて変化し得るものではあります。下記では汎用的に有効と思われるアプローチを考えます。 コンテキスト（何を渡すか） モデルに渡す情報の取捨選択です。モデルはコンテキストに入っている情報しか処理できないので、必要な情報をいかに過不足なく届けるかが重要です。 ただし、多ければよいというわけではありません。不要なものも大量に含めてしまうと、肝心の情報が埋もれて精度が落ちることになります。 関連するファイルやドキュメントのパスを渡す 長い履歴は要約して圧縮する 過去の経緯はメモリとして持たせ、必要なときに参照させる 過去の経緯を覚えておくメモリも、結局はその時々でモデルに渡すコンテキストの一部です。何を入れ、何を入れないかを設計することがコンテキストという要素の肝になります。 ツール（何ができるか） ファイルの読み書き、コマンド実行、検索、外部APIの呼び出しなど、モデルが現実の世界に働きかけるための道具です。 ツールがあって初めて、テキストを生成するだけのモデルが実際にコードを書き換えたり、テストを実行したりできるようになります。このとき、ツールの粒度や説明をモデルが正しく選択できる状態になっているかによって精度は大きく変動します。利用方法や目的が曖昧なツールだと、モデルに誤った使い方をされやすくなります。 権限・実行環境（どこまで許すか） ツールを与えるということは、モデルに実環境を触らせるということです。そのため、どこまでを自動で許すかの設計が必要になります。 サンドボックスで隔離する、権限モードによって実行範囲を絞る、破壊的な操作の前には確認を挟む、といった仕組みがこれに該当します。自動的に実行される範囲を広げるほど待機時間は減りますが、想定していない現象が発生したときの被害も大きくなります。 速さと安全のトレードオフの設計が重要です。 検証ループ（どう確かめるか） モデルの出力が正しいかどうかを、機械的なフィードバックとしてモデルに戻す仕組みです。テスト結果、型チェック、lint、実際に動かしたときの出力検証などがこれに該当します。 結果の検証が可能かどうかで成果は大きく変化します。検証ループの速さと確かさは、エージェントの賢さの大きな要因です。 4つの要素を動かすもの 4つの要素はいわば部品なので、これらを組み合わせて実際に仕事をさせるには、部品を方向づけ繰り返し動かす仕組みが必要です。 システムプロンプト モデルに対し、どのような役割、どのような方針で動いてほしいかを伝える指示です。 役割やルール、守ってほしい制約をあらかじめ与えるこの指示もハーネスの一部と考えることができます。ここではその場限りの指示を毎回書くのではなく、ハーネスの一部として作り込んでおく対象に変わったと言えます。 エージェントループ 部品をつなぎ、実際にタスクを前に進めるのがエージェントループです。考える→ツールを使う→結果を観測→考える、という繰り返しの制御フローを指します。 このループによって一度の応答で終わらず、失敗を踏まえて何度もやり直しながらゴールに近づくことができます。同時に、いつ止めるか、何回までやり直すかといった歯止めの設計も重要です。終了条件がなければエージェントは延々と動き続けてしまいます。 全体像と具体例 ここまでの要素を図にすると、おおよそ次のような関係になります。 Claude Code でいうと もう少し具体的に、コーディングエージェントのClaude Codeに当てはめてみます。 一般的なAIエージェントは自前でハーネスを構築していることが多いため、ユーザーが用意するファイル群はハーネスの一部にすぎず、ツールやループといった土台はClaude Code本体が提供しているという点に注意が必要です。 ユーザーが用意する層 コンテキスト CLAUDE.md、メモリ、作業中に渡すファイル システムプロンプト CLAUDE.md やスキルで与える役割・方針 権限・実行環境 settings.json でのツール許可やサンドボックスの設定 Claude Code本体が提供する層 ツール ファイルの読み書き、検索、コマンド実行、MCPなど 検証ループ hooks やテスト実行の仕組み エージェントループ 考える→ツール→観測→また考える、を回す中核 ただしこの線引きは必ずしも固定されていません。本体が提供する層であっても、検証ループは hooks やテスト実行の指示で何をいつ確かめるかを、エージェントループは進め方の指示で振る舞いを、ユーザー側からある程度調整することができます。 たとえばCLAUDE.mdには、方針（システムプロンプト）や参照（コンテキスト）に加えて、検証や進め方の指示も書けます。1つのファイルが複数の要素に対応していることになります。 # CLAUDE.md ## 方針（システムプロンプト） - コミットメッセージは英語、conventional commits 形式で書く - 既存コードのスタイルに合わせる ## 進め方（エージェントループ） - 大きな変更は、まず計画を示してから実装する ## 検証（検証ループ） - 変更後は npm test と npm run lint を必ず通す - テストが落ちたら、修正してから完了とする ## 参照（コンテキスト） - API仕様は docs/api.md を参照する 権限・実行環境のほうは .claude/settings.json などで設定します。 { " permissions ": { " allow ": [ " Read ", " Edit ", " Bash(npm test) " ] , " deny ": [ " Bash(rm:*) " ] } } これらはいずれもハーネスの一部です。ツールやループといった土台はClaude Code本体が担っており、両者を合わせて初めて一つのハーネスとして機能することになります。 AI-DLC との関係 最近では、AWSが提唱するAI-DLC(AI-Driven Development Life Cycle)のように、AIを中心に据えた開発方法論も出てきています。AgileやScrumに代わる開発プロセスそのものを再設計しようとするものです。 ポイントとしては、こうした方法論はハーネスの上に乗る上位のレイヤーであるということです。AI-DLCが掲げるAIが計画して人間が承認し実装に進むという流れも、成果物を蓄積して引き継ぐ仕組みも、各作業単位で良いハーネスが組まれていることが前提になっています。 このような方法論を導入してもうまくいかないとしたら、その下のハーネスが整っていない可能性があります。 まとめ AIエージェントの賢さとは、モデルとしての性能が全てではなく、コンテキスト、ツール、権限・実行環境、検証ループといった環境に左右されます。 AIエージェントを使いこなすうえでは、ハーネスの設計がエンジニアに求められる重要なタスクになると考えています。