クリアコードではFluentdおよびFluent Packageのメンテナンスを継続的に行っています。2026年6月にリリースしたFluentd v1.19.3と、9月にリリースしたFluentd v1.19.4では、複数の脆弱性に対応しました。脆弱性対応では、コードの修正に加えて、報告者とのやり取り、非公開でのレビュー、CVE番号の申請、修正版のリリース、アドバイザリーの公開といった作業が必要になります。普段OSSをメンテナンスしていても、これらの操作に触れる機会は多くないかもしれません。2021年にもGitHubセキュリティアドバイザリーを公開したときの記事を書きました。今回は実際のスクリーンショットを使って、GitHub Security Advisoriesで報告を受け付けてから公開するまでの手順と、CVEの採番などで経験した待ち時間を共有します。脆弱性対応の流れここでは、GitHubの公開リポジトリでPrivate Vulnerability Reportingを有効にして、外部から非公開の報告を受け付ける場合を扱います。報告内容を確認し、受理してドラフトのアドバイザリーにする一時的なプライベートフォークで修正とレビューを進める公開文面を整え、CVE申請とIPAへの届出・JVNの公開日の調整を進める修正を公開リポジトリへマージし、修正版をリリースするアドバイザリーを公開するCVE番号の申請とIPAへの届出は、アドバイザリーの準備と並行して進めました。IPAへの届出後には、こちらのリリース予定日を伝え、JVNでの公開日を調整しています。GitHubでの公開後は、CVEやNVDへの反映も確認します。以下の画面は2026年7月から9月に撮影したものです。複数の脆弱性への対応から、それぞれの操作が分かる画面を選んでいます。画面内のタイトルなどは作業途中の情報を含むため、個々の脆弱性の最新情報は公開済みのアドバイザリーを参照してください。1. 報告を確認し、ドラフトとして受理する非公開で脆弱性が報告されると、リポジトリの「Security and quality」タブにある「Advisories」から確認できます。受付時の状態は Triage です。内容を確認して「Accept and open as draft」を選ぶと、非公開のまま Draft になります。詳し

2026年10月29日に通常版 Fluent Package v6.1.0をリリースしました。本記事では、Fluent Package v6.1.0の変更内容を紹介します。通常版とは不具合修正だけではなく、新機能や実験的な変更を含んだリリースです。エンタープライズ用途では、長期サポートを提供するLTS版の利用を推奨しています。本記事の公開時点のLTS版の最新バージョンはv6.0.5となっています。Fluent Package v6.1.0Fluent Package v6.1.0 では、以下の対応を行いました。同梱のFluentdをv1.20.1に更新Rubyのバージョンを 3.4.12 にアップデートしました同梱しているgemの更新rpm: RHEL 9.xや10.xの古いバージョンとの互換性を改善しましたmsi: エンタープライズサービスへのリンクが壊れていたのを修正しましたrpm deb: LTOをRHEL 10.xおよびUbuntuでは無効化しましたWindows版で nokogiri の同梱を終了しました。nokogiri がインストールされていない場合に winevt_xml パーサーは REXML を使用し、in_windows_eventlog2 のブックマーク検証は従来より緩くなりますWindows ARM版のインストーラーの提供をはじめましたパッケージ提供時に packages.fluentd.org を経由するようにしました変更内容の詳細同梱のFluentdをv1.20.1に更新しましたv1.19.xで見つかった脆弱性の修正に加え、各種不具合を修正したv1.20.1を同梱しています。v1.20.x の詳細についてはFluentd v1.20.0をリリースを参照してください。Rubyのバージョンを3.4.12にアップデート前回の通常版のリリースは、v6.0.0であり、そのときにはRuby 3.4.5を同梱していました。そのため、当時のバージョンからはいくつかの脆弱性修正が含まれています。uri: CVE-2025-61594 (Ruby 3.4.7で修正)rexml: CVE-2025-58767 (Ruby 3.4.8で修正)zlib: CVE-2026-27820 (Ruby 3.4.9で修正)net-imap: CVE-2026-47240

先日、クリアコードはWindows向けポップアップウィンドウ抑止ツール「PopGuard」の提供を開始しました。Microsoft Windowsの標準機能には、通知を抑える「応答不可」や「フォーカス セッション」があります。これらは主に画面の隅に表示される通知バナーを抑止することができますが、アプリケーションが独自に表示するリマインダーや確認ダイアログなどのウィンドウは抑止できません。そのため、作業中や画面共有中にも前面に表示されてしまいます。こうしたWindowsの通知設定では抑止できないウィンドウを抑止するため、PopGuardを開発しました。本記事では、PopGuardを実際に使用する手順・設定方法について紹介します。抑止対象ダイアログここでは、抑止対象のダイアログとして、Microsoft Outlook（従来のOutlook）のアラーム通知ダイアログを例として採用します。Outlookのオプションで、［詳細設定］→［リマインダー］→［他のウィンドウの上にリマインダーを表示する］を指定していると、アラームの表示時にほかのウィンドウより手前に表示されます。（ただし、後述のログで確認するとおり、Windowsの最前面固定（TopMost）のウィンドウではありません。）通知を見逃さないため、普段は上記の設定で手前に表示されるように設定しているものとします。Web会議で通話中は、このダイアログが表示されないように抑止することを考えます。抑止対象ダイアログの詳細の確認PopGuardは、抑止中でなくても、トップレベルウィンドウ（親のないウィンドウ）の表示を検知すると、そのウィンドウの情報をログに出力します。このログ出力機能を利用して、抑止対象のダイアログの詳細を確認します。なお、ログに出力されるのは、PopGuardの起動後に表示されたウィンドウです。ログは%LOCALAPPDATA%\PopGuard\PopGuard.logに出力されます。まず、Windowsのタスク バーの通知領域（タスクトレイ）に、PopGuardが表示されていることを確認します。この状態で抑止対象のダイアログを表示させ、ログファイルを開きます。ログにはほかのウィンドウの情報も出力されるため、ダイアログを表示させた時刻の行を探します。今回の例では、以下のようなログが出力されます。2026-1

クリアコードではログデータ収集ソフトウェアの1つであるFluentdの継続的な開発に参加しています。その成果の1つとして、Fluentdのエンタープライズにおける長期運用に適したLTS版のパッケージ（Fluent Package）の提供を主導しています。本記事では、配布しているパッケージの利用動向に関して、scarf.shを導入して簡単に把握できるようにする方法について紹介します。scarf.sh導入の背景かつてFluentdに各種プラグインを統合したオールインワンパッケージとして提供されていたのがTD Agentです。これをリブランディングして提供を開始したのがFluent Packageです。リリース体制等も刷新した最初のリリースはFluent Package v5.0.0で2023年8月のことでした。それから、v6.0.0へのメジャーバージョンアップを経て現在もv6のLTSの提供を続けています。Fluentdをとりまく状況はFluent Package提供開始時点から大きく変化しています。v7で対応するディストリビューションの選定を含め、今後のFluent Packageの提供方針を検討するうえで、利用動向の分析は欠かせません。しかし、開発者側で適度な粒度の利用動向の情報を得られるしくみは整っていませんでした。幸いFluentdはCNCF傘下のプロジェクトであり、scarf.shからCNCF枠としてスポンサー利用できることがわかったため、CNCFに申請して導入をしてみることとしました。利用が多いディストリビューションやバージョンのサポートを優先したり、EOLを判断したりする際の参考になることを期待しています。計測するのは、Scarfを経由したパッケージやリポジトリメタデータへのアクセスです。稼働中の環境数を直接示すものではありませんが、ディストリビューションやバージョンごとの利用動向を推測する材料として活用します。導入前後のFluent Package配布のしくみ導入前の状況は次のとおりでした。docs.fluentd.orgのインストール手順において、インストール用の簡易スクリプトを案内しているdeb、rpm、msiなどのパッケージをCNCFによるCloudflare R2リソースを利用して提供しているしかし該当Cloudflare R2に関するアナリティク

2026年10月23日にFluentdの最新版となるv1.20.0をリリースしました。v1.20系の最初のリリースです。Ruby JITをデフォルトで有効にしたほか、退避したバッファーファイルの容量制限や、ログファイルの検出・読み取りの改善などを実施しました。本記事では、公式サイトで公開している情報を日本語で解説します。更新時の注意点Ruby 3.2のサポート終了Fluentd v1.20.0では、Ruby 3.3以降が必要になりました。Ruby JITを既定で有効にするのに使うRubyVM::YJIT.enableが、Ruby 3.3以降を要求するためです。Ruby JITのデフォルト有効化<system>セクションのenable_jitのデフォルト値をtrueに変更しました。各ワーカープロセスでYJITを有効にすることで、スループットの向上が期待できます。一方で、ワーカープロセスごとのメモリー使用量は増加します。従来の動作を維持したい場合は、次のようにenable_jit falseを設定してください。<system> enable_jit false</system>WindowsではYJITがサポートされていないため、この設定は効果がありません。その場合は、Ruby JIT is not available on this Rubyというログをinfoレベルで出力します。詳細はenable_jitのドキュメントを参照してください。Fluentd本体でのyajl-rubyの使用終了Fluentd v1.19.0から、JSON処理にはデフォルトでjson gemを使用しています。今回のリリースではJSONストリームのパースにもjson gemを使用するようにしました。対象には、in_execと組み合わせて使うparser_jsonや、JSONを受信するin_forward、in_unixなどが含まれます。これにより、Fluentd本体ではyajl-rubyを使用しなくなりました。必要なjson gemのバージョンはv2.21以降です。この変更に伴い、入力ストリームがJSONドキュメントの途中で終了した場合の動作が変わります。従来はParseErrorが発生していましたが、今後は警告を出力して末尾の不完全なデータを破棄します。ストリームが途切れる前に受信した完全な

はじめに組み込みLinuxで動画を再生するとき、ハードウェアデコーダーをGStreamerから利用できる環境があります。では、そのデコーダーをChromiumからも利用するにはどうすればよいでしょうか。GStreamerで再生できることと、Chromiumの動画デコード処理から呼び出せることの間には、もう一段の接続が必要です。その橋渡しをする自由なソフトウェアがv4l-gstです。クリアコードでは、お客様のご要望に応じた業務として、v4l-gstの機能追加、不具合修正、保守を行っています。v4l-gstは、もともとIgel社によって開発されたソフトウェアです。クリアコードではこれをフォークし、独自に開発・保守を続けています。改良の出発点となった実装は、V4L2とGStreamerを接続する可能性を示すPoC（概念実証）の段階にあるように見えました。クリアコードでは、この設計を生かしながら不具合修正を重ね、対象環境でプロダクション利用に耐える水準へと整えてきました。今回は、v4l-gstの仕組みと、実運用に向けた改良例を紹介します1。V4L2の向こう側をGStreamerにするLinuxには、動画デバイスなどを扱うV4L2というAPIがあります。動画のデコードでも、圧縮データを入力し、復号した画像を受け取る「メモリー間（mem-to-mem）」のインターフェースを利用できます。Chromiumには、このV4L2を利用する動画デコードの実装があります。一方、GStreamerでは、パーサーやデコーダーといった処理部品をつないでパイプラインを構成します。ハードウェアデコーダーを利用する部品が提供されていれば、パイプラインに組み込んで使えます。v4l-gstは、この2つのインターフェースをつなぎます。v4l-utilsに含まれるライブラリーであるlibv4l2のプラグインとして動作し、V4L2の呼び出しをGStreamerの操作に対応付けます。アプリケーション側にはV4L2のメモリー間デバイスのように見えますが、その先ではGStreamerのパイプラインが動きます。図の灰色の矢印は呼び出しや操作の関係、緑色の矢印はパイプライン内のデータの流れです。描画の経路やプロセスの配置は省略しています。設定ファイルでは、例えば次のようにパイプラインを指定します。[H264]pipeli

ブラウザでもGroongaで検索したい阿部です。Groongaがブラウザで動くようになったのでさっそく試してみた記事です。この記事に関係する動画もあるので、動画もどうぞ。 はじめにリポジトリの例のとおりにやれば使えます。これは自分でビルドする例です。このとき、一つだけ注意があってWASI SDKというのを事前にダウンロードして配置しておく必要があります。この記事では例に従わず、すでにビルド済みのバイナリを使う方法で説明します。とりあえず動かしてみたいときは、この方法のほうが簡単だからです。ビルド済みのバイナリはGitHubのリリースページにあります。次の流れで説明していきます。環境など準備必要なファイルの取得とりあえずブラウザで動かすGroongaのドキュメントを検索1. 環境など準備OSとかは何でも良いです。Node.js v24以上があれば良いです。今回はDockerを使います。$ mkdir groonga-wasm # 適当なパスに作業用のディレクトリを作る$ cd groonga-wasm$ docker container run -it --rm node:26 --versionv26.11.1注: Node.jsのバージョンが古いと動かない（coreを吐いて落ちる）ので新しいバージョンでお試しください。2. 必要なファイルの取得WASMを使うサンプルコードはリポジトリにあるので、リポジトリをcloneします。加えてWASMのバイナリを取得します。# 上からの続きで作業用のディレクトリ`groonga-wasm`にいる前提sudo apt install -y git wget # gitとwgetがない場合はインストール（Debian、Ubuntuの例）git clone --depth 1 https://github.com/groonga/groonga.gitwget https://github.com/groonga/groonga/releases/download/v16.1.3/groonga-wasm-16.1.3.tar.gztar -xzf groonga-wasm-16.1.3.tar.gzこの例ではGroongaのバージョン16.1.3を使っています。適宜変更してください。試す時点の最新を使うとより良いです。注: 16.

Ruby関連の開発に参加する人が増えるといいなぁと思っている須藤です。2027-02-09（火）の日中にRubyアソシエーションさんがRubyエコシステム開発入門ワークショップを開催します。前回はギフティさんが会場を提供してくれましたが、今回はSmartHRさんが会場を提供してくれます！前回のワークショップに参加してくれたSmartHRのkinoppydさんが次はSmartHRでやろうとかそんな感じのことを言ってくれて社内調整をしてくれた結果です！ありがとうございます！ワークショップ開催が次の会場決定につながったということはよいワークショップだったと思いませんか！？そんなワークショップでRubyエコシステムの開発に参加しはじめてみませんか？このワークショップはRuby本体やRubyGems（Ruby on RailsやActive RecordもRubyGemsの1つなのでRuby on Rails関連も対象です！）の開発に参加してみたいけど敷居が高そう・どこからはじめればよいかわからないなどといった理由で最初の一歩を踏み出せていない人たちをサポートするワークショップです。RubyKaigiのようなカンファレンスや各種Rubyコミュニティなどに参加すると、使うだけではなく開発にも参加したくなるものですが、このワークショップに参加するとそういった人たちが実際に行動に移せるようになるはずです！ワークショップ情報開催日時：2027-02-09（火）10:00-17:00イベントページ： https://rubyassociation.doorkeeper.jp/events/198831参加費：無料会場：SmartHR Space（住友不動産六本木グランドタワー8F）ワークショップ終了後、SmartHRさんのご厚意で無料で懇親会を開催します！ワークショップで一緒に最初の一歩を踏み出したみんなと交流したり、ワークショップで扱わなかった関連する話題をまわりの人に聞いたりできます。ワークショップの内容ワークショップは大まかに言うと次のような流れになります。OSSやRuby界隈の関連情報の説明（座学）対象のプロダクト（Ruby本体またはなにかRubyGemsを1つ）を決めるREADME相当のドキュメント通りに対象のプロダクトを使ってみる（インストールしてサンプルを動かすなど）3.

古いWeb業務システム（Webアプリケーション）には、旧バージョンのIEでないと正しく動作しないものが存在します。その対策として、Microsoft EdgeのIEモードでは、Enterprise Mode Site List（サイトリスト）の <compat-mode> によって、サイトごとにどのIE相当で動作させるかを指定できます。指定できる値は次の3系統です。IE11 / IE10 / IE9 / IE8 / IE7 / IE5 : ドキュメントモード指定IE8Enterprise / IE7Enterprise : エンタープライズモードDefault : 指定なしこのうちエンタープライズモードについては、「ドキュメントモード指定より互換性が高い」という説明を各所で見かけます。では、両者は具体的に何が違うのでしょうか。違いの一つであるドキュメントモードの決まり方については、MicrosoftのFAQやフローチャートで詳しく解説されています。しかし、サイトリストの指定によって変わるのはドキュメントモードだけではありません。本記事では、ドキュメントモードに加えて「ActiveXコントロールから見たIEのバージョン」と「送信されるユーザーエージェント文字列」に注目し、サイトリストの指定ごとに何が変わり、何が変わらないのかを、実際に動作させて確認した結果を紹介します。前提: 本記事で扱う4つの要素本題に入る前に、本記事の比較で扱う4つの要素について整理しておきます。前半の「X-UA-Compatible」と「DOCTYPE」は、IE（MSHTML）がドキュメントモードを決めるときに参照する、サイト側の要素です。サイトリストの設定は、この2つとの組み合わせで最終的なドキュメントモードが決まります。後半の「ActiveXコントロールから見たIEのバージョン」と「ユーザーエージェント文字列」は、ドキュメントモードとは別に、サイトリストの設定によって変わる要素です。サイト側のX-UA-CompatibleX-UA-Compatible は、サイト側から「このページをどのドキュメントモードで描画してほしいか」をIEに伝えるための指定です。HTMLの meta 要素、またはHTTPレスポンスヘッダーのどちらかで指定します。<meta http-equiv="X-UA-Compa

OSS Gateの立ち上げメンバーの一人の須藤です。2026年10月3日（土）にOSS Gate 10周年記念カンファレンスOSS Gate Pass 2026を東京のアンドパッドさんのオフィスで開催しました！私は初めて行ったのですが、すごく立派なオフィスでした。撮影：尾籠盛さん、ライセンス：未設定（イベントレポートのためだけに利用可能）うまく表現できないのですが、このイベントは終わってからなんか不思議な気持ちになりました。これまでの私が企画するイベントは、こんなコンセプトでこんな内容にしてこんな結果になるといいなぁというのを私が考えることが多かったです。今回もそういう感じで進めていましたが、OSS Gate 10周年記念カンファレンスの内容について悩んでいるで書いたとおり、ピンときていませんでした。その後、チャットでみんなに助けてもらって内容を調整したのですが、それでなんかいい感じの結果になりました。それで、なんかすごいなぁと思ったのです。ね、うまく表現できていないでしょ？内容前半はみんなからのトークで、おやつ+自己紹介タイムを挟んで、後半はディスカッションでした。みんなからのトークでは、OSS Gateに参加してその後の行動が変わったみたいな話もあり、OSS Gateをやってよかったんだなぁという気持ちになれました。安川さんはこの日のために2月にオプティムさんで開催したワークショップの動画編集を仕上げて公開してくれました。おやつ+自己紹介タイムは、あってよかったなぁと思いました。はじめましての人がどうして参加したのかを知れたりとか、お久しぶりの人の近況を知れたりとか。自己紹介タイムって意外と時間が必要なので、よほどのことがないと内容に入れない（たとえばクリアコード20周年記念イベントとか）のですが、入れてよかったなぁと思いました。田原さんが提案してくれたのでした。30人弱という人数もちょうどよかった気がします。なお、おやつは荻窪のル クール ピューさんのタルトにしました。トッピングはラズベリーとマスカットと巨峰で、↓はラズベリータルトです。撮影：尾籠盛さん、ライセンス：未設定（イベントレポートのためだけに利用可能）ディスカッションは、私はあまりうまくやれるイメージがなくて内容に入れない企画なのですが、これも田原さんが提案してくれてやってみました。やってみたら、う

先日、当社でご提供しているThunderbirdの法人向け技術サポートサービスのお客さまより、「Thunderbird 153以降のバージョンでタグが保存されなくなった（タグが失われるようになった）」というトラブルのお問い合わせを頂きました。そこで調査を行った結果、Bug 650623の修正で行われた変更が原因で、そのような現象が起こる可能性があることが分かりました。当該タグが日本語などの非ASCII文字で6文字以上の長さで、メールサーバーがGmail以外のIMAPサーバーである場合、本件と同一の事象と考えられます。本記事では、この現象が発生する背景を説明し、暫定的な回避方法をご紹介します。原因冒頭で紹介したBug 650623は、元々は2011年に報告された問題で、非ASCII文字のタグがIMAPサーバー上で破損するというものです。これは、Thunderbird 152およびそれ以前のバージョンにおいて、非ASCII文字を含むタグ名を「内部的に、UTF-7でエンコードし、さらにアルファベットの大文字を小文字に統一した後の文字列で識別する」仕様であったことに起因して発生していた問題です。この問題の修正として、Thunderbird 153およびそれ以降のバージョンでは、非ASCII文字のタグは「内部的に、Quoted-Printable形式に変換した文字列で識別する」仕様に変更されました。この結果、例えば 日本語 というタグ名の場合、Thunderbird 152以前で作成したときの内部名は &zevnliqe- となっていましたが、Thunderbird 153以降で作成したときの内部名は =e6=97=a5=e6=9c=ac=e8=aa=9e となるようになりました。ここで注目して欲しいのが、Thunderbird 153以降での変換後の内部名は元の文字列より大幅に長くなっているという点です。Quoted-Printableでは非ASCII文字の1バイトの文字は3文字になり、日本語の文字は基本的に3バイトで表現されることから、文字数で言うと9倍に膨れあがることになります。ここに、IMAPでメールサーバー上のメールに設定するタグを「表示名」ではなく「内部名」の方で管理するというThunderbirdの仕様と、IMAPサーバーが受け付けるタグの最大文字数の制約が組み

2026年9月29日にFluentdの最新版となるv1.19.4をリリースしました。v1.19系のメンテナンスリリースとなっており、fluent-package LTS版のv6.0.5に同梱してリリースしました。本記事では、公式サイトで公開している情報を日本語で解説します。Fluentd v1.19.3リリース後に見つかった追加の脆弱性を修正しています。v1.19.3の脆弱性修正の一部に不備が見つかったため、Fluentd v1.19.4への更新を推奨しています。Fluentd v1.19.4では、いくつかの不具合・脆弱性を修正しました。脆弱性修正Fluentd v1.19.4では複数の脆弱性を修正しました。Incomplete Fix for CVE-2026-44024: Path Traversal Bypass via Bare .. Tag in Output PluginsCVE ID: 採番待ち（採番され次第、本記事を更新します）CVSS v3 score: 7.5/10 (Critical)脆弱性：Fluentd v1.19.3の脆弱性修正に不備があり、.. がタグに含まれている場合への対応が漏れていた問題を修正しました。Out-of-Memory DoS via Object Allocation Amplification in in_http ndjson parsingCVE ID: 採番待ち（採番され次第、本記事を更新します）CVSS v3 score: 7.5/10 (High)脆弱性：in_http でndjsonのパースに不備があり、OOM由来のサービス拒否(DoS)につながる脆弱性を修正しました。Remote Memory Exhaustion in in_syslog TCP/TLS Mode via Unbounded Connection BufferCVE ID: 採番待ち（採番され次第、本記事を更新します）CVSS v3 score: 7.5/10 (High)脆弱性：in_syslogの処理に不備があり、OOM由来のサービス拒否(DoS)につながる脆弱性を修正しました。Incomplete Fix for CVE-2026-44160: DoS via Unbounded Decompression in Buffer

2026年9月29日にLTS版 Fluent Package v6.0.5をリリースしました。本記事では、Fluent Package v6.0.4の変更内容を紹介します。Fluentd v1.19.3リリース後に見つかった追加の脆弱性を修正しています。一部Fluentd v1.19.3の脆弱性修正の不備を解消しているため、Fluentd v1.19.4を同梱しているv6.0.5への更新を推奨しています。Fluent Package v6.0.5Fluent Package v6.0.5 では、以下の対応を行いました。脆弱性対応のため同梱のFluentdをv1.19.4に更新Rubyのバージョンを 3.4.11 にアップデートしました同梱しているgemの更新(ojは複数のクラッシュする問題やメモリリークの解消、jsonはCVE-2026-54696のバッファオーバーフロー対策です)msi: インストール直後に表示されるポップアップウィンドウにおいて、エンタープライズサービスへのリンクの誤りを修正しました (#1079)rpm: RHEL 9.xや10.xの古いバージョンとの互換性を改善しました (#1089, #1090))rpm deb: LTOをRHEL 10.xおよびUbuntuでは無効化しました(#1102)Fluent Packageをすぐに更新できない場合には、後述する緩和策を適用するか、個別に脆弱性が修正されたgemのインストールを推奨しています。変更内容の詳細脆弱性対応のため同梱のFluentdをv1.19.4に更新Fluent Package v6.0.5 では、Fluentd v1.19.3以前に複数の脆弱性が発覚したため、それらを修正したFluentd v1.19.4を同梱するようにしました。閉域網（信頼されているネットワーク内）での利用には影響ありません。脆弱性が報告されたバージョンを含むパッケージは、次の通りです。fluent-package v6LTS: v6.0.4以前のすべてのバージョン通常版: v6.0.0 (通常版の更新はしばらく予定されていないので、LTSへの移行を推奨します。)fluent-package v5LTS v5.0.9以前のすべてのバージョン (v5.0.xはすでにサポート終了しているので、v6 LTSへの移行を推

「ThunderbirdでPOP3のメールサーバーを利用している状態1から、Microsoft 365のOutlookに乗り換える」といった移行シナリオでは、Thunderbirdに保存された古いメールをどうやって閲覧するかが課題となります。最も簡単なのは「古いメールを保持した状態のThunderbirdを閲覧専用で残しておく」やり方ですが、この場合、古いメールを元に返信したり転送したりしようと思うと、その都度手作業でメールを新環境にコピーする必要が生じます。新環境のメールアカウント2をThunderbirdに作成すれば、受信済みのメールをドラッグ＆ドロップで新環境に持ち越せますが、手動操作には操作ミスの危険がありますし、ユーザーが手順をなかなか実施してくれない恐れもあります。そこでこの度、このような問題を解決する簡易的なソリューションとして、メールサーバー間でのメールの移行処理（コピー処理）を自動化し、組織単位でのメールシステム移行を支援するThunderbirdアドオン「Migrate Messages Between Accounts」を作成しました。本記事では、このアドオンを使ったメールアカウントの移行の仕方を解説します。準備「Migrate Messages Between Accounts」がやることはシンプルで、Thunderbird上で複数のメールアカウントがある状態において、指定に基づいて「移行元アカウント」から「移行先アカウント」へと保存済みのメールをコピーします。動作するためには、以下の準備が必要です。移行先メールアカウントの作成アカウント間の移行ルールの定義Thunderbirdはアドオンからメールアカウントを作成する機能を提供していないため、移行先メールアカウントの準備だけは別途行わなくてはなりません。グループポリシーでもメールアカウントの作成までは行えないため、管理者側で一括して行うためにはMCD（AutoConfig）を使う必要があります。移行ルールの定義アカウント間の移行ルールはポリシー設定で定義します。Active Directory（以下、AD）用のポリシーテンプレートがあり、テンプレートを導入すると「管理用テンプレート」配下に「Thunderbirdアカウント間メッセージ移行」という項目が表示されるようになります。それぞれの項目

OSS Gateの立ち上げメンバーの一人の須藤です。OSS Gate 10周年記念カンファレンスを10月3日に開催するよ！でアナウンスした「OSS Gate Pass 2026」の開催日が近づいてきました。2026年10月3日（土）の13:30から、東京のアンドパッドさんのオフィスで開催します。8月は忙しくてほとんど告知できませんでした（8月が忙しくなることはわかっていたのでこれは想定通り）が、9月に入ってもグダグダしてしまってあっという間に月末になってしまいました。当日の内容をまだ決めかねているのですが、このままだとまたグダグダしてしまいそうなので、ひとまず記録しておきます。なにか助けてくれそうな人はOSS Gateのチャットに来てください！どんなイベントにしたいかアナウンス記事では「これまでの10年のOSS Gateの活動のおかげでなにかしらよいことがあった！ということを共有」するイベントにしたいと書きましたが、なんか弱いなぁという気持ちになっています。10年で成果はあったと思っていますが、それを確認するだけで十分なのか？というとそうでもない気がしています。この10年、とくにこの数年でOSSを取り巻く環境は変わってきました。たとえば生成AIの性能向上やソフトウェアサプライチェーン攻撃の増加などです。OSS Gateは「OSS開発に継続的に参加する人を継続的に増やす」ために活動していますが、これからも今までの延長線上での活動でよいのか、あるいはよくないのか。そういうことも考えたほうがよいのではないかという気がしています。OSS Gateのワークショップでは、「PRをマージしてもらおう！」とか「PRマージ数を稼ごう！」というスタイルではなく、「開発している側にとってうれしい・助かる開発への参加の仕方はこういう感じだからそれでやってみよう」というスタイルでやっています。しかし、この数年の変化を捉えきれているかというと十分ではありません。現状を確認した上で今後のことも考えられるイベントにもできたらいいのかもしれません。タイムテーブル現時点で決まっているタイムテーブルはこんな感じです。13:00-：開場13:30-：オープニング13:35-13:45：OSS Gateをオプティムで開催したよ！ by kaigokan-op13:45-13:55：OSS Gate Work