AIを活用すれば、テストケースやテストスクリプトの作成、テスト結果の分析など、これまで人が時間をかけていた業務を効率化できます。 一方で、「AIが作成したテストケースをそのまま採用してよいのか」「重要な確認項目が抜けていないか」と不安を感じる場面も少なくありません。 生成AIは、自然で説得力のある内容を出力できても、実際の仕様とは異なる情報を生成することがあります。 さらに、ソースコードやログ、顧客情報などを入力することで、情報管理上のリスクが生じる可能性もあります。 そのため、AIによるテスト管理で大切なのは、すべてを自動化することではなく、 AIに任せる範囲と人が判断する範囲を明確にすること です。 AIを便利な補助役として活用しながら、人が品質をコントロールできる仕組みを作ることで、効率化と品質保証を両立しやすくなります。 そこで今回は、AIでテスト管理をする際に押さえておきたい注意点と、安全に活用するための運用方法を実務の流れに沿ってまとめました！ AI導入を検討している場合はもちろん、すでにテスト業務で生成AIを使い始めている場合にも確認しておきたい内容です。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テスト管理ツール11製品の完全比較はこちら▼ 【2026年最新】テスト管理ツール11製品の徹底比較！【脱Excel】 AIでテスト管理をするなら、まず知っておきたい5つの注意点！ AIを活用したテスト管理では、テストケースの作成や結果分析など幅広い業務を効率化できます。 実際に、テストケースやテストスクリプトの作成、テスト実行、テスト結果の分析などはAI活用が進んでいる領域です。 ただし、効率化できるからといって、そのままAIへ任せきるのは避ける必要があります。 生成AIには誤った情報を生成する可能性があり、さらに利用するデータやAIエージェントへ与える権限によっては、品質問題だけでなくセキュリティ問題につながることもあります。 まずは、AIをテスト管理へ取り入れる前に押さえておきたい5つの注意点を確認していきましょう。 AIの回答は「正解」ではない！テストケースの誤りや抜け漏れを前提に確認する 生成AIが作成したテストケースは、完成品ではなく 人が確認するためのたたき台 として扱うことが重要です。 生成AIでは、事実とは異なる内容を自然な文章で出力する「ハルシネーション」が発生する場合があります。 正確な情報を与えた場合でも誤った出力が生じる可能性があるため、「AIが自信を持って回答しているから正しい」と判断するのは危険です。 テスト管理でも、存在しない仕様を前提としたケース、期待結果の間違い、条件の取り違え、似た内容の重複などが混ざる可能性があります。 また、100件のテストケースが生成されたとしても、重要なリスクを確認できていなければ、網羅性が高いとはいえません。 特に確認したいのは、 仕様との一致、テスト観点の漏れ、期待結果の妥当性、重複、優先順位 です。 AIが作った項目数ではなく、「重大な不具合につながる条件を確認できているか」という視点で評価することが大切です。 最終的な採用判断は、仕様や要求、業務上のリスクを理解している人が行う運用にしましょう。 AIだけでは拾いにくい！業務知識・異常系・非機能要件を見落とさない 生成AIは、入力された仕様書や要求事項から一般的なテストケースを展開することを得意とします。 しかし、 仕様書に書かれていない背景や現場特有の事情まで自動的に理解できるとは限りません 。 たとえば、「この操作は実際のユーザーが頻繁に間違える」「以前この組み合わせで重大障害が起きた」といった知識は、資料として与えなければ反映されない可能性があります。 AIは過去のパターンを利用した分析を得意とする一方、まれに発生するものの影響が大きい不具合や、新しい利用パターンなどを適切に優先できないこともあります。 正常系だけでなく、境界値、異常入力、権限違い、通信障害、同時操作、タイムアウトなどが含まれているか確認しましょう。 性能、セキュリティ、アクセシビリティ、ユーザビリティといった 非機能要件 も、人が意識して補う必要があります。 「AIにすべてのテスト観点を考えてもらう」のではなく、「人が重要な観点を定義し、AIに展開してもらう」と考えると、AIを活用しながら品質を保ちやすくなります。 仕様書や不具合情報をそのまま入力しない！機密情報の漏えいを防ぐ AIをテスト業務で利用する際は、 何を入力してよいかを事前に決めておくこと が欠かせません。 テスト担当者が普段扱う仕様書、ソースコード、ログ、障害票、問い合わせ履歴、テストデータには、社外へ出してはいけない情報が含まれていることがあります。 特にソースコード、ユーザー情報、内部文書などを外部のAIサービスへ入力する場合は、データ漏えいや知的財産に関するリスクを考慮する必要があります。 利用するAIサービスについて、入力内容が保存されるのか、モデル改善などに利用されるのか、管理者側で利用状況を確認できるのかを事前に調べておきましょう。 必要に応じて、学習利用を制限できる企業向け環境や、組織として管理できるサービスを選択する方法もあります。 本番環境の情報を使用する必要がない場合は、個人情報を匿名化したり、値をマスキングしたり、ダミーデータへ置き換えたりする方法も有効です。 担当者ごとの判断に任せず、 入力可能な情報と入力禁止の情報を明文化すること が、安全なAI利用の基本となります。 勝手なAI利用を放置しない！ツール・権限・利用範囲を決める AI活用では、公式に許可されていないAIサービスを従業員が業務で使用する シャドーAI にも注意が必要です。 業務を効率化しようという善意から始まった利用でも、会社側が把握していないサービスへ仕様書やソースコードを入力すれば、情報管理上の問題が発生する可能性があります。 そのため、「AIは禁止」とするだけでなく、業務で利用できるAIサービスやアカウント、用途を明確にすることが重要です。 さらに注意したいのが、AIエージェントをテスト管理ツールやリポジトリへ接続するケースです。 文章を生成するだけのAIとは異なり、AIエージェントはファイル変更や外部システムへのアクセスなどの操作まで行う場合があります。 必要以上の権限を与えると、誤った判断によってテストケースや重要データが変更されるリスクが広がります。 AIへ与える権限は 業務に必要な最小限の範囲 に絞り、重要な変更や削除については人の承認を必須にすると安心です。 「なぜこのテストをしたのか」を残す！説明できないAI運用を避ける AIを使ってテストケースを生成する場合、完成したテストケースだけを残す運用には注意が必要です。 後から障害が発生した際、「なぜこのケースを採用したのか」「なぜこのテストを省いたのか」を確認できなければ、原因分析や改善が難しくなります。 AIによる判断が増えるほど、 結果だけではなく判断までの過程を追える状態 を作ることが重要になります。 たとえば、参照した仕様、AIへ与えた指示、生成されたテストケース、人が修正した箇所、確認者、承認者などを必要な範囲で記録します。 AIシステムでは、判断の理由が十分に見えない場合があり、生成された推奨内容をそのまま信頼すると危険な前提をテスト工程へ持ち込む可能性があります。 AIエージェントを利用する場合も、操作ログを残し、想定外の動作が発生した際に追跡できる仕組みが重要です。 AIを利用しても品質保証の責任そのものがAIへ移るわけではないため、「誰が確認し、誰が判断したか」を説明できる運用にしましょう。 AIに任せる仕事と人が判断する仕事を切り分けよう！ AIでテスト管理を成功させるためには、「AIに何ができるか」だけでなく、 どこまでAIへ任せるか を考える必要があります。 生成AIは、大量の情報整理やテストケース候補の作成など、人が時間を取られやすい作業を短縮する力があります。 一方で、ソフトウェア品質には動作の正しさだけでなく、使いやすさ、セキュリティ、性能、ビジネス要求への適合など複数の視点が含まれます。 すべてをAIに任せようとするのではなく、AIが得意な処理と、人の経験や判断が必要な処理を組み合わせることが重要です。 ここからは、AIと人の役割をどのように分けるとよいかを整理します。 AIが得意なのは「たたき台づくり」と「大量処理」 AIが力を発揮しやすいのは、 一定の情報をもとに候補を大量に作る作業や、情報を整理する作業 です。 たとえば、仕様書からテスト観点の候補を洗い出したり、テストケースやテストスクリプトの初稿を作成したりする用途があります。 既存テストケースの分類、表現の統一、似たケースの抽出、テスト結果や障害情報の要約にも活用できます。 AIを使ったテストでは、テスト生成や結果分析、変更に応じたテストの調整など、従来より幅広い工程を効率化できるようになっています。 こうした作業では、人がゼロから文章や一覧を作成する時間を短縮できるため、AI活用による効果を得やすくなります。 ただし、AIが作った内容をそのまま品質保証の根拠にするのではなく、あくまで 判断材料を高速に作る補助役 として利用するのがポイントです。 人はAIが作った材料を確認し、業務知識やリスクを踏まえて必要なものを選び、修正する役割を担います。 人が手放してはいけないのは「品質基準」と「最終判断」 AI活用が進んでも、 何をもって品質が十分と判断するのか は人が決める必要があります。 テスト対象には、単純な動作確認だけでは判断できない要求が数多くあります。 たとえば、ユーザーが迷わず操作できるか、重大事故につながる使い方がないか、法令や社内基準を満たしているかといった判断には、業務や利用者への理解が必要です。 人は「利用者が想定外の操作をしたらどうなるか」「画面の流れが分かりにくくないか」といった、文書化された仕様だけでは捉えにくい問いを立てることができます。 テスト方針、優先順位、テスト終了基準、重大不具合の判定、リリース可否など、説明責任を伴う判断は人が担うのが基本です。 重要なワークフローでは、 人がAIの出力を確認する仕組み を組み込むことが、安全性を高めるポイントになります。 AIが処理を高速化し、人が品質を判断する役割分担を作ることで、効率化と信頼性を両立しやすくなります。 AIに任せる範囲は「失敗したときの影響」で決める AIへ任せる範囲を決める際は、作業が簡単か難しいかだけではなく、 AIが間違えた場合の影響度 で考える方法が実践的です。 たとえば、テストケース候補の文章を整える作業であれば、人が後から修正しやすいためAIへ任せやすいでしょう。 一方、重大な不具合の判定やテスト省略の判断、リリース可否などを誤ると、ユーザーや事業への影響が大きくなる可能性があります。 影響が大きい処理ほど、人によるレビューや承認を厚くする必要があります。 特にAIエージェントがテスト管理ツールへ直接変更を加える場合は、重要な操作に人の承認を挟む仕組みが有効です。 最初から完全自動化を目指すのではなく、 AI生成→人によるレビュー→承認 という流れから始めると、問題点を把握しながら段階的に利用範囲を広げられます。 評価するときも自動化率だけを見るのではなく、作業時間、レビュー工数、修正量、欠陥検出、手戻りなどを含めて判断しましょう。 安全にAIを使うなら、チームで守る運用ルールを決めよう！ AI活用の安全性を担当者個人の知識や注意力だけに頼ると、使い方にばらつきが生まれます。 同じチームでも、ある担当者は機密情報を入力せず、別の担当者は仕様書をそのまま入力しているという状態になれば、組織としてリスクを管理できません。 AIの業務利用が広がるなかでは、安全な利用に向けて組織内の規程や体制を整えることが重要なテーマとなっています。 また、生成AIを利用するシステムでは、利用目的から必要な品質を定め、各構成要素へ管理策を設定する考え方も重要です。 AI利用を禁止するのではなく、安全に使える共通ルールを作ることで、現場がAIのメリットを活かしやすい環境を整えましょう。 最初に決めたい！AI利用ルールのチェック項目 AI利用ルールを作る際は、最初から複雑な規程を作ろうとせず、 誰が・何を・どこまでAIに任せられるのか を明確にするところから始めましょう。 まず、業務で利用を許可するAIサービスやアカウントを決め、未承認サービスを個人判断で使わないようにします。 次に、入力できるデータと入力禁止データを分類します。 個人情報、顧客情報、非公開のソースコード、認証情報、未公開製品の仕様などは、情報の重要度や利用サービスの契約条件を踏まえて扱いを決める必要があります。 さらに、AIが生成したテストケースを誰が確認するのか、どの作業で承認が必要なのかを決めます。 プロンプト、生成結果、修正内容、実行ログ、承認者など、後から確認する必要がある情報の保存範囲も整理しておきましょう。 会社が把握していないAIの利用を防ぐためには、 利用可能なAIを分かりやすく提示し、現場が正式な環境を使えるようにすること も大切です。 AI生成テストはこの順番でレビューする！ AI生成テストを効率よくレビューするためには、担当者ごとに確認方法を変えるのではなく、 チェックする順番を決めておくこと が有効です。 最初に確認したいのは、要求や仕様と一致しているかです。 存在しない機能や誤った前提が含まれていれば、それ以降のテスト内容も正しく評価できません。 次に、正常系、異常系、境界値など必要なテスト観点が漏れていないかを確認します。 その後、それぞれの期待結果が正しいか、似た内容が重複していないか、重要度の低いテストが大量に生成されていないかを見ていきます。 最後に、過去障害、問い合わせ、業務上の例外、性能やセキュリティなど、 AIだけでは判断しにくい現場固有の観点 を補います。 テスト観点を体系化して提示することは、生成AIを利用するシステムのテストケースを多様化するうえでも有効性が検討されています。 この確認手順をチェックリスト化すれば、AI活用者が増えてもレビュー品質をそろえやすくなります。 小さく試して効果を測る！AI導入を成功させる進め方 AI導入では、最初からすべてのテスト工程を置き換えようとせず、 限定した業務から試すこと が重要です。 たとえば、既存仕様からのテストケース候補作成や、テスト結果の要約など、失敗しても人が修正しやすい作業から始めます。 試行前には、テストケース作成時間、レビュー時間、修正数、欠陥検出数など、比較したい指標を決めておきましょう。 AI導入後に作成時間が半分になっても、レビューや修正に以前より時間がかかっていれば、チーム全体では効率化できていない可能性があります。 AIモデルや利用環境によって出力特性が変わる可能性もあるため、一度評価して終わりではなく、継続して品質を確認することが必要です。 生成AIを利用するシステムでも、想定用途から品質要件を定め、各構成要素へ必要な管理策を適用する体系的な品質管理が重視されています。 効率とリスクの両方を数値や事例で確認し、問題なく運用できる範囲から徐々に広げること が、無理のない導入につながります。 AIを「品質保証の代役」ではなく「品質を高める補助役」にしよう！ AIをテスト管理へ導入する目的は、人の判断をすべてなくすことではありません。 AIには、大量の情報を短時間で処理し、テストケースやスクリプトの候補を生成したり、テスト結果から傾向を見つけたりできる強みがあります。 一方、人には、利用者の行動や業務背景を理解し、重大なリスクを見極める強みがあります。 AI支援型の品質保証では、 効率を高める場所と、人の専門性を残す場所を慎重に選ぶこと が重要です。 AIと人を競わせるのではなく、それぞれが得意な部分を組み合わせることで、テスト管理全体の品質を高めていきましょう。 AI導入の目的を「テスト件数を増やすこと」にしない 生成AIを使えば、短時間で大量のテストケースを作ることができます。 しかし、生成された件数が多いほど品質が高いとは限りません。 重要性の低いケースや似たケースが大量に生成されれば、確認する側の負担が増え、かえって重大なテスト項目を見落としやすくなる可能性もあります。 AIテスト支援では、過去の傾向から重要度を推定したりテストケースを生成したりできますが、まれに起こる重大な不具合や新しい利用状況を正しく評価できない場合があります。 そのため、AI導入の評価指標を「何件作ったか」や「何％自動化したか」だけにしないことが大切です。 重要な欠陥を発見できたか、レビュー負荷が下がったか、手戻りが減ったか、品質を保ったまま時間を短縮できたか まで確認しましょう。 AIによって浮いた時間を、仕様レビューや探索的テスト、リスク分析など、人の判断が価値を生みやすい作業へ振り向けることが、本来の効率化につながります。 「AIを使っているから不安」から「AIを使っていても説明できる」状態へ 安全なAI活用で目指したいのは、「AIだから信用する」状態でも、「AIは危険だから使わない」状態でもありません。 AIがどこで使われ、何を生成し、誰が確認し、誰が最終判断したのかを説明できる状態 を作ることが重要です。 AIに任せる業務、人がレビューする業務、承認が必要な業務を明確にすれば、担当者ごとの判断のばらつきを抑えられます。 さらに、プロンプトや生成結果、修正履歴、承認記録を必要な範囲で残しておけば、問題が発生したときにも原因を追いやすくなります。 AIが理由を十分に説明できないままテストの省略やリスク評価を提案する場合もあるため、重要な判断では根拠を確認できる仕組みが欠かせません。 利用ルールやレビュー基準をチェックリストとして共有すれば、特定の担当者だけがAIを使いこなせる状態から、チーム全体で安全に活用できる状態へ移行できます。 AI活用そのものを目的にせず、 品質を説明できるテスト管理を維持しながら効率を高めること を目指しましょう。 まとめ｜AIに任せきらず、人が品質をコントロールできるテスト管理へ！ AIをテスト管理へ取り入れることで、テストケースやスクリプトの作成、結果分析などの作業を効率化できます。 一方で、AIには誤った内容の生成やテスト観点の抜け漏れがあり、入力するデータによっては情報漏えいのリスクも考えられます。 AIエージェントを外部ツールと連携させる場合は、必要以上の権限を与えないことや、重要操作に人の承認を入れることも大切です。 AIが作った結果は完成品ではなく、 人が確認して品質を高めるためのたたき台 と考えると、安全に活用しやすくなります。 AIには大量処理や候補作成を任せ、人は品質基準、リスク判断、最終承認といった役割を担当しましょう。 まずは「利用できるAI」「入力できる情報」「レビュー方法」「承認者」「残す記録」の5点を整理すると、運用ルールを作り始めやすくなります。 最初から完全自動化を目指す必要はありません。 小さな範囲からAIを試し、品質と工数の変化を確認しながら、安全に任せられる範囲を少しずつ広げていくことが重要です。 AIを品質保証の代わりにするのではなく、人がより重要な品質判断へ集中するための補助役として活用していきましょう。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

テスト観点は「出す」より「削る」ほうが難しい。 前回の記事で「テスト観点の書き方」を紹介しました。画面要素を列挙する、仕様書から名詞と動詞を抜き出す、AIに壁打ちする。これで「出す」はできるようになります。 でも、出した観点を全部テストできますか？ ! この記事を読んでほしい人 テスト観点の出し方は覚えた。次に「絞り方」を知りたい人 AIでテスト観点を出してみたけど、量が多すぎて困った人 「何をテストしないか」の判断に自信がない人 試しにClaudeに「ECサイトの決済機能のテスト観点を出して」と投げてみてください。100個くらい、平気で出てきます。正常系、異常系、境界値、セキュリ

はじめに ZOZOTOWN開発本部のらぷ（ @laprasdrum ）とイッセー（ @15531b ）です。WWDC現地参加は、らぷは2016年以来2回目、イッセーは初参加（かつ初渡米）です。本記事ではWWDC26の現地参加レポートとともに、ZOZOのiOSエンジニアによるおすすめセッション、6月18日に開催されたLINEヤフー株式会社との合同報告会イベントについてもご紹介します。 目次 はじめに 目次 WWDC26のSpecial Event Day 0 Day 1 Keynote Download stations Platforms State of the Union 現地視聴をより楽しむために In-person labs Inner ring reception Day 2 Developer session Mixer @Developer Center Theater event 併催コミュニティイベント おすすめセッション集 優れたデザインのための原則 Foundation Modelsフレームワークの新機能 WWDC26 報告会 at LINEヤフー, ZOZO さいごに WWDC26のSpecial Event 今年6月7日〜9日（現地時間）のWWDC26では、昨年と同様に招待制のSpecial Eventが現地開催されました。昨年の様子は「WWDC25現地参加レポート」をご覧ください。 techblog.zozo.com 今年のSpecial EventはWelcome receptionから始まりました。基調講演後には、Appleの方へ新APIを質問したりアプリのフィードバックをもらえたりするIn-person labsが開かれました。その後、Apple ParkのInner ringで交流会がありました。最終日はSteve Jobs Theaterで、スター・ウォーズ作品『The Mandalorian and Grogu』の上映とスペシャルゲストのインタビューを楽しめました。 Date Pacific Time Content Venue Day 0 (June 7) 3 p.m. Welcome reception Infinite Loop Day 1 (June 8) 8 a.m. Check-in Apple Park 10 a.m. Keynote Apple Park After Keynote Download stations open Apple Park 12 p.m. Lunch Apple Park 1 p.m. Platforms State of the Union Apple Park After Platforms State of the Union In-person labs Apple Park 4-6 p.m. Reception in the inner ring Apple Park Day 2 (June 9) 10 a.m. Developer session Steve Jobs Theater or Apple Developer Center Cupertino 11:30 a.m. Mixer Apple Developer Center Cupertino 8 p.m. Pre-show presentation and special screening of The Mandalorian and Grogu Steve Jobs Theater Day 0 私たちはDay 0の午前にSFO（サンフランシスコ国際空港）へ到着し、宿泊先のホテルに荷物を置いてからInfinite Loopへ向かいました。道中は初めてWaymoを利用しました。急カーブでもほとんど揺れずに走行するため、仮眠できるほど静かでした。 Infinite Loopに到着するとチェックイン待ちの長蛇の列がすでにできていました。並んでいる間のおもてなしとして配られたジェラートバーとお水で暑さをしのぎつつ待ちました。 2種類の味から選べたジェラートバー 入口前でセキュリティチェックを済ませると、参加者用のバッジとノベルティを受け取りました。バッジにはNFCタグが入っており、各イベントのチェックイン時にAppleのスタッフのiPhoneにバッジをかざすことになっています。ノベルティ恒例のピンバッジにはLil Finder Guyと創立50周年を象徴するデザインが含まれていました。入場時はAppleのスタッフの方々が歓声とともに出迎えてくださり、Day 0から盛り上がりを肌で感じました。 今年のノベルティバッグ 今年のピンバッジ、ステッカー、ボトル 参加者用バッジ ── お気に入りのピンバッジを添えて その後は終了時刻の夕方7時まで自由に過ごしました。軽食とドリンクをいただきながら各国の参加者との交流、Apple Design Awardsの受賞者とファイナリストとのトーク、Appleのスタッフによるモニュメント前の記念撮影などを楽しみました。 快晴に恵まれたこの日 モニュメント前で記念撮影 また、APACの参加者で集まって記念写真も撮りました。オフラインで参加すると、多くの方がApple Platformの開発者として関わっていることを実感できました。 Day 1 Keynote まずはKeynoteの会場に向かうため、Visitor Center前でチェックインを済ませてApple Parkに入場しました。入場まで横断歩道の信号待ちで列がゆっくり進む中、Caffè Macsのスタッフからいただいたドーナツを食べながら近くの方と「今年のWWDCは何を期待してますか？」と雑談しました。話しかけた方の多くがAIのトピックを気にされていました。 Visitor Center前のチェックインも長蛇の列 Caffè Macsからいただいたオレンジ味のドーナツ 会場に到着したのは8時半頃でした。Keynote開始時間の10時までは自由に散策し、参加者とお話を楽しみました。 KeynoteおよびPlatforms State of the Unionの会場 会場のスクリーンでは、オンラインで公開されているKeynoteの動画が再生されます。現地では動画の再生前にCraig Federighi氏がステージに登場し、挨拶がありました。 developer.apple.com 続いてTim Cook氏も登場し、このときの会場の盛り上がりは強烈でした。CEOとしてのKeynoteでの登壇は今年が最後です。参加者全員が立ち上がってiPhoneを掲げて撮影する光景を前に、Cook氏自身も「これまでこんなにiPhoneに囲まれたことはありません」と語っていました。 壇上に登場したTim Cook氏 Download stations Keynoteが終了すると、高速の有線ネットワークが提供されるDownload stationsに集まりました。ここでXcode 27 BetaやiOS 27 Betaのダウンロードを始めました。この日は晴天で気温も高かったため、パラソルの影に集まって休憩する参加者も多かったです。 有線ネットワークが用意されたDownload stations Platforms State of the Union developer.apple.com 手元にiOS 27 BetaをインストールしたiPhoneを触りながら、先のKeynoteの内容も踏まえてPlatforms State of the Unionを視聴しました。今回のSiri AIやCore AI、Foundation Modelsなどのアップデートには、共通した方向性があります。デバイスへ蓄積された写真やテキストなどのパーソナルなデータをもとに、AI体験を最適化することがAppleの狙いです。Newsroomで公開されたSiri AIの記事には、Apple Intelligenceのアーキテクチャ図が掲載されています。この図では、デバイスとアプリケーション（またはSiri AI）の間にユーザーコンテキストが示されています。Appleプラットフォームのアプリ開発者には、このコンテキストを活かしたAI活用が求められているのでしょう。 www.apple.com 視聴後しばらくすると、スクリーン上にさまざまなアプリのアイコンが表示されました。幸運なことに弊社のアプリが映し出されたタイミングで撮影できました。 どこかにある弊社アプリのアイコン。見つけられましたか？ 現地視聴をより楽しむために 現地ならではの視聴の楽しみ方も、二人それぞれ工夫してみました。らぷは Rokid Glasses というスマートグラスのリアルタイム翻訳機能を使って視聴しました。体感1秒未満で翻訳結果が表示されたので和訳文も追いつつ快適に視聴できました。 Rokid Glassesのリアルタイム翻訳結果 イッセーは英語に自信がなかったため、セッションの視聴でAirPods Proのライブ翻訳機能を試しました。実際に使ってみると、登壇者の英語が純正の翻訳アプリ上に日本語テキストとして表示されるだけでなく、AirPodsからも日本語に翻訳された音声がリアルタイムで流れてきます。この機能のおかげで、英語に自信がなくてもセッションの内容を大まかに理解できました。イッセーとしては、画面上のテキスト翻訳はあえて見ず、登壇者の様子を見ながら日本語音声だけを聞くスタイルがとても快適でした。 ライブ翻訳機能の翻訳結果 私たち以外にもスマートグラスやAirPodsを使って視聴している参加者が多くいました。海外カンファレンスへ現地参加する際の言語の壁はこれまでもありましたが、こうした技術によって乗り越えやすくなったと感じました。 In-person labs Platforms State of the Unionが終了するとIn-person labsが始まり、各ラボで新しく発表されたAPIや日々の開発で困っていることを相談しに行きました。特に困ったことがなくても「まだ触れたことのないFrameworkを始めようと思うんだけど何から始めたら良いですか？」といった相談でも問題ありませんでした。気さくな雰囲気の中でいろいろ話せるので、来年現地に行かれる方はぜひ積極的に利用してみてください。 Inner ring reception その後夕方6時まではInner ring内で自由に過ごしました。Xcode 27 Betaで開発したり、初対面や既知の開発者との会話を楽しんだり、Appleの方に質問したりと、あっという間に時間は過ぎていきました。 Xcodeダウンロード中にAppleのWWDRの方にいただいたFoundation Models Frameworkのステッカー 虹のApple Stage前で撮影してもらったイッセー。青いシャツの方は各国のApple Storeのスタッフ Day 2 Developer session Developer sessionに参加するため、Apple Parkへ向かいチェックインを済ませました。今回のセッションはSteve Jobs Theaterで開催されました。ここは過去のWWDCでは立ち入ることができなかった特別な場所です。定員制のため、シアターに入れない場合はApple Developer Centerでの視聴でした。開始1時間前に到着したものの、すでに多くの参加者が列を作っていました。皆がこのシアターでの参加を待ち望んでいる熱気を感じました。 無事に入場でき、ガラス張りの円形の建物と緑豊かな造形美に圧倒されました。会場で軽い朝食をとった後、いよいよセッションがスタートしました。 Developer session前のSteve Jobs Theaterの様子 今回のセッションでは、Xcode 27の「Agentic Coding」やFoundation Modelsなどの新しいAIフレームワークが取り上げられました。実際のアプリ開発にどう組み込むかという実践に焦点を当てた内容です。その中でも、Evaluations Frameworkはどのように役立てられるのかイメージができていませんでした。セッションを通して、LLMの出力の品質を容易にテスト・評価できる点を理解でき、実際に触ってみる良いきっかけになりました。動画でも公開されているので、使い方のイメージが付いていない方の参考になります。ぜひチェックしてみてください。 developer.apple.com Developer sessionの様子 Mixer @Developer Center セッション終了後はDeveloper Centerへ移動し、「Mixer」というイベントに参加しました。会場にはさまざまなフードトラックが用意されており、昼食をとりながらコーディングをする人々の姿も見られました。また、特定のテーマごとにブースが設けられており、参加者同士で交流したり、Appleのエンジニアに直接質問したりできる貴重な場となっていました。さらに、Developer Center内ではGroup Labが開催されており、会場の内外いずれも非常に活気に満ちていました。 テーマごとに交流ができる場所 Mixerの会場図 Theater event 夜は、現地参加者の中で先着申し込みができた「Theater event」に参加しました。日中と同じくSteve Jobs Theaterで開催されるとのことで、再びあの空間に足を踏み入れることができました。 Theater eventでのSteve Jobs Theater 今回上映されたのは、今年公開されたスター・ウォーズ作品『The Mandalorian and Grogu』です。上映前にはスペシャルゲストによる対談が行われていました。その際、通路の透明なディスプレイに会話の文字起こしと手話がリアルタイムで表示されていました。Appleらしいアクセシビリティへの高い配慮に、とても驚かされました。スター・ウォーズにあまり精通していなかったため少し心配でしたが、思った以上に内容が分かりやすく、シーンによっては観客の歓声で盛り上がるなど、非常に楽しむことができました。 インタビュー中に字幕と手話が表示される透明なディスプレイ 併催コミュニティイベント らぷはCommunityKitが主催している2つのイベントに参加してきました。ひとつはPaul Hudson氏が開催した「What's new in iOS 27?」です。 luma.com WWDCでは、Day 1にAppleから全セッション動画とサンプルプロジェクトが公開されます。Hudson氏はSwiftUIやSwiftDataなどのサンプルプロジェクトを実際にビルドし、発生したエラーと修正方法を紹介してくださいました。すべてのサンプルプロジェクトが修正なしで期待どおりに動作するわけではないので、こうした知見を聞けるのは助かります。 会場の様子 もうひとつは「Swift Contributor Social」というイベントです。こちらはSwiftのコントリビューターと、それに興味がある人たちによる交流会です。まだコントリビューターではありませんが、どんな観点で活動しているのか聞いてみたくて参加しました。 luma.com 今回はstdlibのメンテナーでSpanの実装を担当された方にじっくりお話を聞くことができました。 developer.apple.com メモリ安全性への興味や今後の展望、コンパイラーチームが別途持っている構想と突き合わせた上での定期的な議論などを伺いました。Swift Forumsを眺めているだけでは得られない情報が多く、刺激的な時間でした。 ボウリング場のビリヤード台を囲んで自由に交流中 参加中、もしくは興味のあるWorking Groupのバッジ おすすめセッション集 優れたデザインのための原則 ZOZOTOWN iOSアプリの開発をしているつっきー（ @tsuzuki817 ）です。 今回のWWDCでは、Appleが考える優れたデザインの原則を扱うセッションがありました。デザインを単なる「見た目やふるまい」ではなく、「意図をもってものを作ること」と定義した上で、数々の重要な指針を解説しています。詳細は「 Principles of great design 」のセッションをご覧ください。 私が特に注目したのは、「主導権」「寛容さ」「柔軟性」という3つの原則のつながりです。ユーザーをあらかじめ決められた道に無理に誘導するのではなく、主導権を人々に委ね、自分のペースで探索させることの重要性が語られています。しかし、自由に探索できるようになると、ユーザーは誤って削除してしまったり意図しない操作をしてしまったりすることがあります。 そこで重要になるのが「寛容さ」です。操作を簡単に取り消せるようにし、大惨事を避けられるようにすることで、ユーザーに「いつでも回復できる」という自信を与え、安全な探索を支えることができます。さらに、ユーザーがアプリを使う状況（ランニング中や運転中など）や能力は人それぞれであるため、それらに適応する「柔軟性」を持たせることも強調されていました。 すべての人に合う単一のレイアウトを見つけるのは難しいため、ユーザー自身が好みに合わせて体験をカスタマイズできるようにすることが、最良の柔軟性です。セッションの最後では、これらの原則を正しく実行した自然な結果として、真の感情的なつながりである「喜び」が生まれると語られていました。これは製品に込めた「思いやりの総和」であるとのことです。自分がアプリを開発するうえで大事にしていることでもあり、同時に難しいと感じている点でもあります。 普段ZOZOTOWNの開発や個人開発をするなかで、ユーザーにどのような体験をさせたいのか迷うことが多くあります。このような原則に則って考えることで、よりよいプロダクトが作れそうだと期待しました。また、この考え方はZOZOTOWNのアプリ開発でぜひ意識していきたいです。さらにユーザーだけではなく、普段の仕事で起きるコミュニケーションにも活かせます。相手に選択肢を委ね、ミスを許容し、状況に柔軟に対応していきます。 Foundation Modelsフレームワークの新機能 ZOZOTOWN iOSアプリの開発をしているpe（ @shumpei_nagata ）です。 今年のWWDCでは、Foundation Modelsフレームワークの進化に興味を惹かれました。詳細は「 What's new in the Foundation Models framework 」で紹介されています。 このフレームワークは昨年登場し、アプリ上でオンデバイスの大規模言語モデルを扱えるようになりました。そして今年は画像入力（Vision）に対応しました。テキストだけだったプロンプトに Attachment(UIImage(...)) のように画像を差し込むと、その画像について回答が得られます。ガイド付き生成（ @Generable ）やツール呼び出しなどの既存APIもそのまま使えるので、これまで書いたコードを活かして画像対応に広げられます。 また、Foundation Modelsの導入に役立つ道具も増えてきました。生成AIは出力が確率論的に決まるので、生成結果の品質を確かめるのはなかなか骨が折れます。サービスの機能として安心して導入するには、品質を測定できる仕組みが必要です。そういった課題には Evaluations Framework が役立ちます。併せてAppleからオープンソースで公開された foundation-models-utilities も参考になります。コンテキスト超過を防ぐトランスクリプトの圧縮やSkills APIなど、Foundation Modelsをより便利に扱えるツールが揃っています。 このセッションが気になったのは、業務と個人開発のどちらでも視覚的な情報を多く取り扱うアプリを開発しているからです。進化したFoundation Modelsフレームワークを組み込むことで、アプリ上の体験を大幅に拡張できそうです。たとえば説明文の作成、属性の抽出、altテキストによるアクセシビリティの補完などが挙げられます。こうした処理が通信なし・無料で、しかもプライバシーを保ったまま端末の中で完結するのは非常に魅力的です。 とはいえ、既存のサービスへ導入するハードルは低くありません。Foundation Modelsは利用にiOS 26以降が必要で、今回の画像入力はiOS 27以降でないと動きません。その上、Apple Intelligence対応デバイスという条件もつきます。またZOZOTOWNはiOSアプリだけでなく、AndroidアプリやWebサイトなどさまざまなプラットフォームでお客様にご利用いただいています。OSや端末が限られる機能をそのまま主役に据えると、体験に大きな差が生じてしまうので、導入の見極めが難しい技術であるのも事実です。 それでも、アプリに導入するとどのような新しい体験を提供できるかとワクワクしました。技術的な好奇心もくすぐられるセッションでした！ WWDC26 報告会 at LINEヤフー, ZOZO WWDC後の6月18日にLINEヤフーと合同で報告会を実施しました。 lycorptech-jp.connpass.com イッセーは「現地で盛り上がったWWDC26 Keynote」というタイトルで登壇しました。 speakerdeck.com 報告会では、実際に現地参加して見えたことを紹介しました。Keynoteで周囲のデベロッパーがどのようなテーマで盛り上がったのか、意外と反応が落ち着いていたテーマはどれか、思いもよらないサプライズは何だったのかを共有しています。一番印象的だったのは、事前に「これが目玉だろう」と考えていたトピックと、会場が実際に沸いたトピックのズレです。この差は公式の発表資料やニュース記事を後から追っても分かりません。世界中のデベロッパーがどのトピックに興味関心があったのかは、その場にいた人にしかわからない情報でした。 らぷはパネルディスカッションに参加し、印象的だったセッションや現地参加に必要な準備などを共有しました。先ほどのスマートグラスの活用や気になったセッションの話も取り上げています。「WWDCに現地参加するなら何をすべきですか？」という質問への回答は、他の参加者やAppleのスタッフの方と積極的にコミュニケーションすることです。これはLINEヤフーのパネラーの方と同じ意見でした。自分にはない考え方に触れたり、同じ考えをもつ同志に出会えたりできる機会です。ぜひ最大限に活用してください。 パネルディスカッションの様子 さいごに 今年のWWDCで感じた現地の雰囲気とおすすめセッション、報告会の様子をお届けしました。この記事を読んで現地での思い出を振り返ったり、新しいAPIの調査を始めて共有したりしていただけると嬉しいです。 ZOZOでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com