2026年8月の主な製品アップデートをご紹介します。 製品アップデート YouTrack連携を改善し、より柔軟な操作が可能に YouTrack連携を改善し、PractiTestからYouTrackを利用する際の操作を、チームがより柔軟に管理できるようになりました。 YouTrackのユーザー権限を反映：アイテムのインポート、課題の報告、同期フィールドの更新など、YouTrackに関連する操作を、各ユーザー自身のYouTrack権限に基づいて実行できるようになりました。 連携設定画面を刷新：設定画面をよりわかりやすく再設計し、PractiTestに同期する情報やフィールドのマッピング方法を、より明確に管理できるようになりました。 詳しくは、 YouTrack連携のドキュメント をご覧ください。 要件トレーサビリティレポートに、より詳細な情報を追加可能に 要件トレーサビリティレポートで、要件、テスト、テストセットに含まれるシステムフィールド、カスタムフィールド、グローバルフィールドを利用できるようになりました。 これにより、プロジェクトにとって重要な情報をより柔軟に盛り込み、詳細なトレーサビリティレポートを作成できます。 詳しくは、 レポート機能のドキュメント をご覧ください。 一括編集をよりスムーズに 複数のエンティティをまとめて編集する操作が、よりスピーディーで使いやすくなりました。 これまでは一括編集を行う際に別ページへ移動する必要がありましたが、今後はポップアップウィンドウ内で編集できます。現在の画面や作業状況を維持したまま、変更作業を進めることが可能です。 今後の予定 PractiTest ライブトレーニング カスタマーサクセスチームによるライブトレーニングセッションに参加して、PractiTestについて知りたいことを何でもご質問ください。 ヨーロッパ：9月9日（水）14:00 CEST 北米：9月9日（水）14:00 EDT／11:00 PDT アジア太平洋地域：9月9日（水）12:30 AWST ライブトレーニングに申し込む PractiTestに関するその他の情報 インテリジェントテスト管理とは？ テストケース管理やテストオーケストレーションの先にある進化 テスト管理は、単にテストケースを保存したり、テスト活動を調整したりするだけのものから進化しつつあります。 インテリジェントテスト管理では、要件、テスト、実行結果、不具合、自動化など、さまざまな品質に関する情報を結び付けます。これにより、チームはデータが何を意味しているのか、何が重要なのか、次にどこへ注力すべきなのかを理解しやすくなります。 ブログ全文を読む テストの背景情報がなければ、AI生成のテストケースがうまく機能しない理由 AIに要件やJiraチケットを渡すだけでは、実際に何をテストすべきかを十分に理解させることはできません。 既存のテスト、テストカバレッジ、不具合、そのほかのプロジェクト情報にアクセスできることが、なぜ適切なテストの生成や実際のテスト不足の特定に欠かせないのか、そしてテストプロセス全体を通じてAIをより有効に活用するために重要なのかを解説します。 ブログ全文を読む ※ PractiTest公式HP より翻訳

G-gen の西原です。Google Workspace 版の Gemini アプリの一時チャットと会話履歴の削除機能について、概要やデータ保存の仕様、管理コンソールでの制御手順を解説します。 概要 一時チャットとは チャット履歴の個別削除とは チャット履歴保存の仕様 通常チャット 一時チャット データの取り扱いとプライバシー 想定されるユースケース 一時チャットのユースケース 通常チャットのユースケース 管理者設定 Google 管理コンソールでの設定手順 Google Vault による保持 概要 一時チャットとは 一時チャット （Temporary Chats）とは、履歴に残らない特別なチャットセッションの中で Gemini アプリと会話ができる機能です。このモードで開始された会話は、チャットを閉じるとサイドバーの履歴一覧には表示されなくなります。その場限りの独立したブレインストーミングや、一時的なテキストの校正などに最適です。 チャット画面で右上のアイコン（画像赤枠）を押下することで、一時チャットを開始できます。 参考 : Gemini アプリで一時的なチャットとチャットの削除を管理する チャット画面で右上のアイコン（画像赤枠）を押下 一時チャット画面 チャット履歴の個別削除とは チャット履歴の個別削除とは、過去に Gemini アプリと行ったやり取りの中から、特定の会話を選択して個別に削除できる機能です。この機能により、不要になった古い会話や整理したい特定の会話だけをピンポイントで削除できるようになり、サイドバーの履歴画面をクリーンに保てます。 Gemini アプリの左部ペインから、削除したいチャット履歴の右側の三点リーダーを押下すると、プルダウンメニューが表示されます。ここで「削除」を選択することで、チャット履歴を削除できます。 参考 : Gemini アプリで一時的なチャットとチャットの削除を管理する 削除したいチャット履歴の右側の三点リーダーから削除を選択 チャット履歴保存の仕様 通常チャット 通常のチャット（一時チャットではない通常のセッション）では、ユーザーが手動で削除しない限り、履歴は保存されます。これにより、過去の指示内容（プロンプト）や、Gemini アプリから得られた回答をいつでも見返し、再使用できます。 通常のチャット履歴の仕様は以下のとおりです。 項目 仕様の詳細 履歴への表示 サイドバーの履歴一覧に常時表示される ユーザーによる削除 個別削除機能により、特定のセッションのみを削除可能 一時チャット 一時チャットは、ユーザーの画面上からはチャット終了後に即座に消去されます。 ただし、Google がバックエンドでデータを保存する仕様には注意が必要です。 Google の公式ドキュメントによると、一時チャットの内容はユーザーの履歴には表示されませんが、バックエンドで最大 72 時間保持されます。したがって、ユーザーの画面から消えても Google のサーバーから完全にリアルタイムで抹消されるわけではありません。ただし、このデータが外部に漏洩したり、一般の生成 AI モデルのトレーニングに使用されたりすることはない、とされています。 参考 : Gemini アプリのプライバシー ハブ また後述のように、組織で Google Vault が使用されている場合は、バックエンドに会話履歴が保存されており、管理者からデータを確認することが可能です。 データの取り扱いとプライバシー Google Workspace ユーザーが最も懸念する点の一つが、「入力したデータが AI の学習データとして使用されるのではないか」という点です。 Google Workspace 向けに提供されている Gemini サービスにおいて、ユーザーが入力したプロンプトや生成された回答は、Google の一般モデルのトレーニング（学習）に使用されることは一切ありません。これは、通常チャットであっても、一時チャットであっても同様です。企業の機密情報や社内データは保護されます。この仕様は、 エンタープライズグレードのデータ保護 と呼ばれます。 またこのデータ保護は Gemini アプリに限った話ではなく、Google Workspace に統合されているすべての AI 機能に共通で適用されます。 参考 : Google Workspace の生成 AI に関するプライバシー ハブ 想定されるユースケース 一時チャットのユースケース 一時チャットは、例として以下のような後から見返す必要性が低い作業に最適です。これらの作業を一時チャットで行うことで、通常のチャット履歴が不要な情報で埋め尽くされるのを防ぐことができます。 文章の単純な校正・翻訳 既存のメール文を英語に翻訳したり、誤字脱字をチェックしたりするだけの作業。 単発のコードデバッグ プログラミング中に出た短いエラーログの原因を特定するためだけの質問。 通常チャットのユースケース 反対に、以下のような「継続的なプロジェクトや、後からプロセスを確認したい作業」では、通常チャットを使用することが推奨されます。ただし、通常チャットに不要なやり取りが混ざってしまった場合でも、チャット履歴の個別削除により履歴を整理することができます。 アイデアの壁打ち まとまっていないブレインストーミングの段階で、キーワードをランダムに投入してアイデアを出す作業。 長期間にわたる企画書の作成 何日かに分けて、徐々にプロンプトをブラッシュアップしながらドキュメントを作り上げる場合。 複雑な調査業務 特定の技術や市場動向などについて、複数の角度から質問を重ねて深い知見を得る場合。 管理者設定 Google 管理コンソールでの設定手順 管理者は、組織部門（OU）や構成グループごとに、ユーザーが「一時チャット」や「履歴の個別削除」を使用できるかどうかを制御できます。具体的な設定手順のイメージは以下のとおりです。 [Google 管理コンソール] に管理者アカウントでログインします。 メニューから [生成 AI] ＞ [Gemini アプリ] ＞ [Gemini との会話の履歴と管理] の項目へと進みます。 新しく追加された [一時チャットと会話の削除コントロール] を確認します。 対象の組織部門を選択し、機能を「許可する」または「制限する」に設定し、[保存] をクリックします。 参考 : Gemini アプリで一時的なチャットとチャットの削除を管理する - 一時チャットとチャットの削除をオンにする Google Vault による保持 企業の法務部門やコンプライアンス担当者が確認すべき点として、Google Vault との連携仕様が挙げられます。 通常チャットの削除 ユーザーが手動で個別にチャットを削除した場合、そのデータはユーザーの画面には表示されなくなります。しかし組織で Google Vault が使用されている場合、Google Vault の保持ルールに従って管理者側で検索・エクスポートが可能です。 一時チャットのデータ保持 一時チャットとして実行された会話データが監査・保持の対象となるかは、組織の Google Vault の使用状況に依存します。Google Vault を使用している組織では、ユーザーが一時チャットを使用した場合でも、Google Vault の保持ルールが優先され、ユーザーには見えないところでデータが保存されます。このデータは、管理者側で検索・エクスポートが可能です。 参考 : Gemini アプリで一時的なチャットとチャットの削除を管理する - Vault と一時チャット、チャットの削除 西原 正真 (記事一覧) 事業開発部 クラウドサポート課 大阪府出身、北海道在住。2026年5月よりG-genにジョイン。 現在は Google Workspace を中心に、カスタマーサポートに従事。 Google Cloud 全 14 資格保有。 好きなものは写真と旅行。

目次 はじめに 前提：私たちのチームの開発の進め方 Working Backwardsに着目した理由 「機能リリース概要」という形にアレンジした 課題は、文章を書く手間 AIで上流工程を効率化する まとめ はじめに 楽楽勤怠の給与計算オプションのプロダクトマネジメント / プロダクトオーナーをしている @k0First です。 機能の仕様を決める際、事業部との認識合わせに何度もやり取りが発生したり、開発に渡した後で仕様の意図を確認されたりすることがあります。原因を振り返ると、多くの場合、最初に作成するドキュメントで伝えるべき情報が伝えきれていないことに行き着きます。 この記事では、Amazonの「Working Backwards」という考え方を参考に、自分たちの開発体制に合わせてドキュメントの作り方を見直し、AIを使って作成を効率化した取り組みを紹介します。 前提：私たちのチームの開発の進め方 会社によって開発の進め方は異なるため、先に前提を整理しておきます。 給与計算オプションでは、機能のロードマップを事前に企画課と協議して決めています。そのうえで、各機能の仕様についてはプロダクトオーナーがドキュメントを作成し、事業部と協議しながら確定させていく流れです。 デザイナーはこのドキュメントをもとにデザインを作成し、バックエンド・フロントエンドのエンジニアは、できあがったデザインとドキュメントをもとに開発を進めます。 つまり、プロダクトオーナーが最初に作成するドキュメントが、事業部との認識合わせの土台になると同時に、デザインや開発の起点にもなります。このドキュメントの内容が不十分だと、その影響は後工程にそのまま伝わることになります。 Working Backwardsに着目した理由 Working Backwardsは、Amazonが新しいサービスや機能を企画する際に用いている手法です。開発に着手する前に、その機能が完成した後を想定した顧客向けのプレスリリースをまず書き、あわせてQ&A（FAQ）をまとめます。この一式はPRFAQ（Press Release and Frequently Asked Questions）と呼ばれています。 開発企画は、放っておくと「今の仕組みや技術でできること」を起点に積み上げがちです。その積み上げ方だと、できあがってから「これは誰の、どんな課題を解決しているのか」が曖昧なまま進んでしまうことが起こり得ます。Working Backwardsは、完成後の顧客向け発表文を先に書かせることで、企画の起点を強制的に顧客の課題や体験に戻す仕組みだと理解しています。プレスリリースという体裁上、専門用語や社内事情に頼った説明ができず、平易な言葉で価値を言い切る必要がある点も、考えを整理するうえで機能しているようです。 この考え方は、私たちが抱えていた課題とも重なる部分がありました。事業部との認識合わせに時間がかかるのも、開発から仕様確認が入るのも、突き詰めると「その機能が何を解決するのか」「仕様の意図は何か」が、最初のドキュメントの時点で言い切れていないことが原因だったためです。 ただし、そのままの形式を持ち込むことはできませんでした。Amazonのプレスリリースは顧客向けの発表文であるのに対し、私たちが作成するドキュメントの読者は事業部や開発メンバーだからです。 そこで、「価値と仕様を先に言語化する」という発想だけを取り入れ、形式は自分たちの読者に合わせて作り直すことにしました。 ※Working Backwardsについては、こちらを参考にしてください。 🔗 参考リンク アマゾンの最強の働き方――Working Backwards （コリン・ブライアー、ビル・カー著） プレスリリース先行で企画を作るAmazon流のやり方【企画の道具箱 #7】 「機能リリース概要」という形にアレンジした 作成したのは、「機能リリース概要」というドキュメントです。 顧客向けのプレスリリースではなく、事業部向けのプレスリリースに近い形式にしました。前半には「どのような機能を出すのか」「その機能が顧客のどのような課題を解決するのか」を記載し、後半には事業部・開発メンバー向けに詳細な仕様を記載します。 さらに、このドキュメントを読んだ事業部や開発メンバーから想定される質問を、Q&A形式でまとめました。1機能につき1ドキュメントとして、機能概要とQ&Aをセットで扱う運用にしています。 この形式にしたことで、事業部との協議は、ゼロから説明するものではなく、すでに言語化された内容をもとに認識をすり合わせるものに変わりました。 課題は、文章を書く手間 一方で、この機能リリース概要には作成コストの課題がありました。 1機能1ドキュメントで、機能概要・詳細仕様・Q&Aまでを揃えるとなると、書く文章量は少なくありません。事業部や開発メンバーに伝わる内容にするには、言葉の選び方にも配慮が必要です。 その結果、仕様の検討そのものよりも、それを文章に落とし込む作業に時間がかかる状態になっていました。上流工程の進め方を変えても、この部分がボトルネックになっては意味がありません。 AIで上流工程を効率化する この課題に対して、次のような流れを取り入れました。 機能リリース概要のテンプレートを、あらかじめ作成しておく テンプレートに沿って、ドラフトを作成する あらかじめ定義したブラッシュアップの観点（Skill）をもとに、AIでブラッシュアップする 完成した機能リリース概要をもとに、Q&AをAIで自動作成する ポイントは、最初のドラフトは自分で書くことです。給与計算オプションは法令や計算ロジックが絡み、仕様の正確性が求められる領域のため、何を書くべきかという判断はプロダクトオーナーが担い、AIには文章を伝わりやすく整える役割を任せています。 ドラフトの作り方自体は、特別なことはしていません。テンプレートの各項目を、まず箇条書きでとりあえず埋めていきます。伝えたい内容がすでに固まっている項目については、箇条書きを飛ばして最初から文章で書いてしまうこともあります。AIに読み込ませることを意識した書き方の工夫は、特にしていません。箇条書きでも文章でも、その時点で自分が把握している情報をテンプレートの構造に沿って書き出しておく、というだけです。 ただし、入力値や出力値があらかじめ決まっている項目については、箇条書きの段階で書き切るようにしています。たとえば給与業務であれば、給与振込FBデータのように対外的に出力する項目の内容は決まっているので、ドラフトの段階で該当する値をすべて列挙しておきます。ここを曖昧にしたまま先に進めると、後工程で認識のズレが起きやすい部分だからです。構造さえテンプレートに沿っていれば、その後のブラッシュアップはSkill側の指示でカバーできるようになっています。 社内には、仕様が固まりきらない案件で、 最初からAIに書かせて書き直させるという進め方をしたチームの事例 もあります。書き直しが前提の、失敗コストが低い領域だからこそ成立する進め方だと考えています。給与計算オプションのように正確性が優先される領域では、人が骨格を作り、AIには磨きを任せる方が適していると判断しました。 ブラッシュアップについては、都度チャットで指示を出すのではなく、どのような観点で直すかをあらかじめSkillとして定義しています。「事業部が読んでもわかる粒度になっているか」「前半と後半で情報の重複や矛盾がないか」といった観点をSkill側に持たせておき、実際の作業ではGoogleドキュメントのリンクを貼り付けるだけで、その観点に沿ったブラッシュアップが行われる形にしています。毎回同じ指示を書き直す手間がなくなり、ブラッシュアップの精度も安定するようになりました。 機能リリース概要が完成した後は、その内容をもとにQ&Aの作成もAIに任せます。ドキュメントを読み込ませたうえで、事業部や開発メンバーが疑問に思いそうな点を洗い出してもらう形です。自分だけで質問を想定すると視点が偏りやすいため、この工程は特に効果を感じています。 この仕組みは、完成後の修正でも活きています。開発中に仕様変更が発生した場合、該当箇所を書き換えたうえで同じブラッシュアップのSkillを呼び出せば、テンプレートの構造や表現ルールに沿った形にすぐ整え直せます。ドキュメントの体裁を保つための調整を都度自分でやり直す必要がなく、仕様変更への対応スピードにもつながっています。 参考までに、ブラッシュアップのSkillに定義している指示の一部を抜粋します。実際にはもっと長い指示書ですが、骨子は次のようなものです。 あなたは、勤怠管理・給与計算システムの「機能リリース概要」をブラッシュアップする編集アシスタントです。 読者は、事業部（営業・カスタマーサクセス・サポート・導入支援）と開発部（バックエンド・フロントエンド・デザイナー・QA・保守運用）を想定します。 # 最重要ルール - 「機能要件（Must / Better）」は、必ず機能単位でテンプレート構造（概要・入力・出力・処理・業務ルール・エラー・備考）を維持する - テンプレート構造を独自変更したり、機能をまとめたりしない # 基本方針 - 社内仕様書として自然な敬体で記載する - 冗長な説明は避ける - 元資料の内容を尊重する - 指定範囲外を大きく変更しない - 不明点は断定しない - 読みやすさよりテンプレート準拠を優先する # 出力形式 - Markdownで出力し、Googleドキュメントに貼りやすい形にする - 「本文タブ用」「Q&Aタブ用」の順にコードブロックで出力する 読者の想定、テンプレート構造の維持、出力形式まで指示に落とし込んでおくことで、Googleドキュメントのリンクを貼るだけでも、毎回一定の品質でブラッシュアップされるようにしています。 この進め方に変えてから、ドキュメント作成にかかる時間は短くなりました。事業部との協議でも、機能の概要説明に使っていた時間を、認識のすり合わせそのものに使えるようになっています。 一方で、AIに任せられない部分もあります。何を書くべきか、どこまでを今回のスコープとするかという判断は、ドメイン知識をもとに人が行う必要があります。AIに任せるのは、内容を伝わる形に整える工程と、そこから疑問点を洗い出す工程で、判断そのものは自分たちで行う。この役割分担が、現時点では最も機能しています。 まとめ Working Backwardsをそのまま自分たちの開発に当てはめることは難しいと感じました。読者もドメインも異なるためです。 一方で、「価値と仕様を、開発に着手する前に言語化しておく」という考え方自体には、取り入れる価値がありました。形式は自分たちの読者に合わせて作り直し、「機能リリース概要」というドキュメントに落とし込みました。 そのドキュメント作成にかかる手間は、AIを活用することで軽減できました。ここでも、AIに何を任せ、何を自分たちで行うかの線引きは、扱っているドメインの特性に合わせて考える必要がありました。 Working Backwardsも、AIの活用も、そのまま取り入れるのではなく、自分たちの体制やドメインに合わせて調整していく。今回の取り組みを通じて、そのことを改めて確認できました。