こんにちは、エンジニアの澤田です。 前回の記事 では、Rust で RgbColor 構造体を使って演算子オーバーロードをやってみましたが、今回はその RgbColor を使ってグラデーションを表現するイテレータを作ってみたいと思います。 私はイテレータを普段の業務であまり意識せずに使っていましたが、イテレータのインターフェースを実装することで理解を深めたいと思い、試してみました！ ※rustc と cargo はバージョン 1.97.1、edition 2024 を使用しています。 イテレータとは イテレータを一言でいうと、 次の要素を1つずつ返してくれるもの です。 配列のように

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 資格保有。 好きなものは写真と旅行。

はじめに 2026年に開催された DroidKaigi 2026 に、弊社の開発本部から 3 名のエンジニアが参加してきましたので、イベントの様子や印象に残ったセッションをご紹介します。 イベントの様子 スポンサーブース エブリーは今回、ゴールドスポンサーとしてブースを出展させていただきました！ 足を運んでいただいた皆様、本当にありがとうございました！ ブース企画 アンケートボード ブースでは、「AI時代！どこまで越境したいですか？」をテーマにした参加型のアンケートボードを実施しました！ Android開発をベースにしつつ、バックエンドやPdM、データサイエンスといった他の領域へどのようにスキルを広げていきたいか、皆様のリアルな声を聞かせていただきました！ 回答いただいた多くの皆様、ありがとうございました！最終結果はこちらです……！ 2日間でいただいたシールは、合計およそ 400 枚。領域ごとの内訳は次のようになりました。 最も票が集まったのは「Android」でしたが、Backend と iOS がほぼ同数で並び、この3つが上位を分け合う形になりました。一方で全体を見ると、Android 以外の領域に貼られたシールは全体の 8 割弱。「Android を軸に据えつつ、その外側にも手を伸ばしていきたい」という方が多数派でした。 また、シールを貼っていただきながら、こんな声も聞かせていただきました。 モバイル領域が好きなので、クロスプラットフォームでやっていきたい コードは AI が書いてくれるので、プロダクトをどうグロースさせるかを考えられるようになりたい 「AI 時代にどう越境するか」という問いに対して、技術の横方向に広げていく方向と、プロダクトづくりそのものへ踏み込んでいく方向、その両方のリアルな声を伺うことができました。 ※シール数は写真からの集計のため、概算値です。 Xフォロー＆くじ引き エブリー開発部の X アカウントをフォローいただくと、くじを1回引けるという企画も実施しました。 景品は、レンジ調理鍋・まな板・計量スプーン・しゃもじ・お箸など、普段の料理で使えるキッチングッズです。 ハズレの方にも、CTO 自らがテイスティングして選んだ「CTO ブレンド」のコーヒーをお渡ししていたので、くじを引いてくださった方には全員何かしらお持ち帰りいただけるようにしていました。 キッチングッズが当たった方に喜んでいただけて、こちらも嬉しかったです！ またXをフォローいただいた皆様、本当にありがとうございました！X ではテックブログの更新情報も発信しているので、ぜひチェックしていただけると幸いです！ ネイル体験会 会場ではプロのネイリストによるネイル体験会が開催されており体験してきました！ 流れとしては、ネイルをする指を2本選び、それぞれのデザインを決めていくというもの。ベースカラーはネイリストの方と相談しながら決められるので、ネイルに詳しくなくても安心して選ぶことができました。 デザインは、DroidKaigi のキャラクター3種類とロゴの中から好きなものをチョイスできました。指先に DroidKaigi のキャラクターがいてくれるので、ふとした拍子に目に入るたび嬉しくなります。 他社のスポンサーブース REALITY さん REALITY さんは、AEP 対応に関するアンケートを行っていました！ AEP (Apps Experience Program) は、Google が指定した要件を満たすと認定を受けられ、Google Play の新しい料金表の適用などの特典が得られるプログラムです。 Material3 は対応済み (80% 以上) の回答が多く、予想以上でした。一方でフルコンポーズ化は、まだ対応中・検討中という回答の方が多いようでした。 アーキテクチャも公開されていました。3D アバター以外の箇所はネイティブで作成されているとのことで、Unity を使っていると思っていたので驚きました。 BIZREACH さん BIZREACH さんは、AI が進化して楽になったことについてアンケートを行っていました！ テストコードの生成やエラーの原因調査のような、コーディング業務の補佐的な立ち位置に留まらず、相談相手として活用している方が多く面白かったです。 晩ご飯の献立については、他と比べると少ないようでした。 デリッシュキッチン の出番のようです！ エムスリー さん エムスリーさんは、毎年恒例の、プログラムのコードが印刷されたクリアファイルを配布されていました。 なんと去年よりコードが短くなっているとのことでした！ クリアファイルの詳細については、昨年版のものになりますが エムスリーさんのテックブログ で公開されていますので、ぜひご覧ください！ セッション紹介 なんとかする力 〜Androidエンジニアからマネージャー、さらにその先へ？〜 発表者: m.coder さん（フラー株式会社） レポート: 岡田 m.coder さんに、「目の前の課題を『なんとかする』の積み重ねが今の自分を作ってきた」という考えをもとに、キャリアとの向き合い方を語っていただいたセッションでした。 仕事のやりやすさは「何を・いつまでに・どこまでやるか」が決まっているかで大きく変わり、曖昧な箇所を明確にして不確実性を下げること自体が価値ある仕事だという話から始まりました。 印象的だったのは、役職が上がっていくにつれ、皆等しく抽象度の高い課題の解決を求められるというお話です。「なんとなくチームの雰囲気が悪い」「なんかプロジェクトの品質が悪い気がする」といった、課題かどうかすら曖昧なものを扱う必要があるという具体例に痛く納得しました。こういった漠然とした課題については、どうしても目を瞑りがちなので、自身のマインドセットを見直す必要があるなと痛感しました。 またテックリードとマネージャーは向き合い方が違うだけで、どちらも「自分以外の領域（チームや組織）をなんとかする」役割だという整理も面白かったです。 自分のキャリアを考えるうえで、抽象度の高い問題に立ち向かうべきという方針や、それを実現させる方法について非常に学びになりました。ご自身の経験から語られている箇所も多く、熱いメッセージをいただいた気持ちになりました。 また冒頭で『エンジニアリング組織論への招待』を紹介していただきました。1 章だけでも読む価値があるとのことなので、ネクストアクションとしてはこちらを読もうと思います。 あなたのANRはどこから？ — 発生する仕組みを診断し、症状別に処方する 発表者: chomi さん（NRIネットコム株式会社） レポート: 岡田 会場が皆うなずいていたセッションだったように思えます。 メインスレッドについての解説を経て、まずは誰しもが経験したことがあるであろう、メインスレッドでの I/O についてのお話から始まりました。その後起動時の重い初期化、ロック競合と進みました。 起動時の重い処理については、特にレガシーコードを触ったことがある人なら対応したことがあるのではないかと思います。本当に Application で初期化すべきかを考えるというのは ANR 以外にも、パフォーマンスの観点から非常に重要です。例として FirebaseSDK の初期化について出ましたが、こちら誰しもがなんとかならないかなと調べたことがあると勝手に思っているので面白かったです。また固有端末依存や Binder 経由の呼び出し先での ANR などについても話があり、やはり皆さん困っているのだなと共感しました。 何より構成と見せ方が完璧だったと思います。スライドは要点だけが目に入る作りで、定義や例などもとても丁寧でしたので、スッと内容が入ってきました。終章の ANR 診断フローチャートについても綺麗にまとめられており、参考になりました。 発表での再現には、公開されているサンプルアプリ DorodoroTimer を用いたそうです。デモモードをONにすると上記の ANR が実際に発生し、コード内の [ANR-xx] マーカーから問題箇所と修正版を見比べられます。 AndroidにおけるServer-Sent Events: 工場の現場を生き抜くリアルタイムストリーム 発表者: Mr. Jasveen Sandral (Industrial Android, Toyota Group Japan) レポート: 鈴木 ( @0muji4_eng ) 本講演は、AndroidにおけるServer-Sent Events（SSE）を用いたリアルタイムストリーミング実装の課題と、その具体的な解決策について論じています。 Webブラウザとは異なり、Androidの標準的なライブラリ（OkHttpなど）にはSSEの自動再接続や状態管理の機能が不足しており、通信障害時にエラーを検知できず画面のデータがフリーズしてしまうエラーケースが存在します。講演者はこの事象を "The Trap of Silence" (沈黙の罠) と呼んでいました。この問題を克服するためには、サーバーに依存するのではなく、クライアント側（Android側）で堅牢な自己回復機能を持つ独自の仕組みを設計する必要性が生じます。 具体的には、サーバーからの定期的な通信（ハートビート）を監視してタイムアウトなどの切断を検知する仕組みや、厳密な状態管理（ステートマシン）の実装が不可欠です。あわせて、再接続時には最後に受信したID（Last-Event-ID）をサーバーへ送信することで、通信断絶中のデータ欠落を補完し、安全にストリーミングを再開する必要があります。 また、頻繁な双方向通信に適したWebSocketとの技術的な比較や、端末がオフラインになった際の適切なUI制御にも触れられています。最終的に、一方向のデータ監視システムにおいてSSEを有効に活用するには、サーバー側でのバッファリングといった設計だけでなく、クライアント側がいかにして通信の切断と復帰に耐えうるアーキテクチャを構築できるかが重要であると結論付けています。 WebAssembly in Android Apps 〜 WASMはJNIの夢を見るか 発表者: keiji_ariyama さん (C-LIS CO., LTD.) レポート: 鈴木 ( @0muji4_eng ) 本講演は、Androidアプリ開発において、C++などで書かれた既存のネイティブライブラリ（OpenJPEG など）を、WebAssembly（Wasm）を用いて安全に再利用するためのアーキテクチャ設計について論じています。 背景として、運転免許証やパスポート、マイナンバーカードなどに格納されている顔写真データ（JPEG 2000形式など）を読み込む際、従来のJNI（Java Native Interface）経由の直接実行では、悪意のある細工された画像データによって深刻な脆弱性を突かれ、アプリ全体が危険にさらされるリスクがありました。 この課題に対する実践的な解決策として、講演者は Wasm と Jetpack JavaScript Engine を組み合わせた多層防御（Defense-in-Depth）を提案しています。Wasmによってシステムコールを持たないメモリ隔離環境（第一層）を構築し、さらにJS Engineによってネットワークやローカルファイルへのアクセス権限を持たない別プロセス（第二層）として実行します。これにより、万が一デコーダーの脆弱性を突かれても、被害をサンドボックス内に完全に封じ込め、アプリ本体への影響を防ぐことが可能になります。 また、実装上の大きな障壁となる プロセス間のデータ転送コスト についても詳細な検証が行われています。文字列変換によるデータ受け渡しでは、プラットフォーム側にネイティブ実装が存在する Base64 を使用するのが最もパフォーマンスが高いことが実証されました。しかし現在では、JS Engine バージョン1.1.0で導入された MessagePort API を活用することで、バイナリデータの双方向通信が可能となり、エンコードのオーバーヘッドが劇的に解消されることが解説されています。あわせて、プロセス間通信の1MB容量制限も、RAM 上のファイルディスクリプターを介することで安全に回避できる点が示されています。 結論として、Wasm はメモリコピーが発生する点（ゼロコピー不可）やコードの隠蔽化に向かない点においてJNIとトレードオフの関係にあります。しかし、外部からの信頼できないデータを処理する要件においては、過去の優れたネイティブ資産を極めて安全にモバイル環境へ持ち込むための、非常に有効なベストプラクティスであると位置づけています。 まとめ 今年は例年と違い、 AI 関連のトピックが増加した印象です！ ブースでは AI を用いた開発に関してのアンケートが多数見受けられました！ セッションでは デバイス操作はAIエージェントの時代へ。mobile-mcpを活用したAndroid UI/E2Eテストの挑戦 や AI に Inclusive UI を書かせよう — Design Rules Skill で Compose UI を作り直す のような AI を開発効率化に用いる内容から、 Google のオープンモデル Gemma を活用した最新の AI 開発のトレンド のような AI 開発そのものについてまで幅広く講演されており、時代の変化を感じました！ またブースには本当に多くの方に足を運んでいただき、たくさんの人にエブリーを知っていただけて、とても良い機会でした！ これからもデリッシュキッチン、エブリーのことをよろしくお願いいたします！ 最後に エブリーでは、ともに働く仲間を募集しています。 テックブログを読んで少しでもエブリーに興味を持っていただけた方は、ぜひ一度カジュアル面談にお越しください！ corp.every.tv さらに、 DroidKaigi & iOSDC After Talks Night 2026 を、ゆめみ、フェンリル、Yappli、WealthNavi、セーフィー、エブリーの6社合同で開催いたします！なお、今回はiOSDC Japan 2026のアフターパーティーも兼ねているので、AndroidエンジニアだけでなくiOSエンジニアの方も交えて、プラットフォームの垣根を越えた活発な技術交流や情報交換をお楽しみいただけます。両カンファレンスの熱気をそのままに、各社によるLTセッションや懇親会をご用意しております。 項目 詳細情報 開催日時 2026年10月2日（金） 19:00 ~ 21:00 開催場所 東京都港区三田一丁目4番1号 住友不動産麻布十番ビル 開催形態 オフライン / オンライン コンテンツ 各社のAndroid & iOSに関するセッション / 懇親会 詳細や参加登録につきましては、以下のリンクよりご確認ください。 yumemi.connpass.com 最後までお読みいただき、ありがとうございました！