Outlookのアドインの開発をしている橋田です。クリアコードではTypicalReplyという、以下のような機能を提供するOutlookアドインを提供しています。受信したメールに定型の内容の返信メールを作成するボタンを追加する例: 「通報」ボタンを押すと以下の内容の返信メールを作成する件名: 迷惑メールの通報宛先: 社内のシステム管理部門元のメールを添付ボタンの設定を組織単位で集中管理するTypicalReplyはVSTOというフレームワーク上で開発されていました。VSTOアドインはクラシックOutlookでのみ動作し、新しいOutlookでは動作しません。今回、お客様から新しいOutlookでもTypicalReplyを使用したいという要望を頂き、新しいOutlookでも動作するTypicalReplyを新規開発しました。新しいOutlookで動作するアドインを作成するためには、Officeアドインプラットフォームでアドインを作成する必要があります。今回は、この開発事例を元に、OfficeアドインでのOutlookのアドイン開発の流れを紹介します。背景: OutlookのアドインについてOutlook向けのアドインの開発の背景として、2026年現在のOutlookおよびOutlookのアドインの状況について説明します。Outlookの種類現在、Windows向けのOutlookにはクラシックOutlook、新しいOutlookの二種類が存在します。また、Web上で使用可能なOutlookとしてOutlook on the webが存在します。クラシックOutlook: Windowsアプリケーションとして開発されていた従来のOutlookクライアントです。新しいOutlook: Webベースで開発された新しいOutlookクライアントです。Outlook on the web: ブラウザ上で動作するWebベースのOutlookクライアントです。Microsoft社はクラシックOutlookから新しいOutlookへの移行を進めており、2029年にクラシックOutlookはサポート外となる予定です。参考情報:https://learn.microsoft.com/ja-jp/microsoft-365-apps/outlook/get-started/guide-

結城です。当社が受託開発を行う際には、なるべく「筋が良い」設計でソフトウェアを実装したり、仕様に問題がある場合は「筋が良い」仕様になるようご提案したりといった要領で、可能な限り技術的に「筋が良い」解決方法を取るように努めています。技術的な制約によって理想的な解決の仕方ができない場合でも、当社では様々な可能性を探り、ご相談を頂いた時点では想定されていなかった方法で問題を解決します。本記事で取り扱うEdge拡張機能の開発事例も、その一つです。本事例では、「Webブラウザー・Edgeの仕様にない挙動を実現したい」という、通常であれば技術的に不可能と思われるご要望を、その背景にあった事情まで遡ってヒアリングして、無事解決まで導くことができました。この記事では、当社が本事例でどのように問題を解きほぐして解決したのかをご紹介したいと思います。頂いたご相談お客様から頂いたお問い合わせは、要点をまとめると「Edgeのコンテキストメニューの『最新の情報に更新（リロード）』『印刷』や、キーボードショートカットの『F5』『Ctrl-R』『Ctrl-P』を無効化したい」というものでした。こちらのお客様とはFirefoxのカスタマイズ案件で既にお取引があり、Firefoxでは特定のキーボードショートカットやメニュー項目をピンポイントで無効化するカスタマイズが可能だったことから、同様のカスタマイズをEdgeで行えないか、ということでお問い合わせを頂いたと考えられます。しかしながら、ChromiumベースのブラウザーであるEdgeは、あらかじめ隠し設定やグループポリシーで制御可能なように実装されている機能以外は、任意で無効化することができません。当社で技術資料を調査した限りでは、Edgeでは印刷操作は無効化できるものの、リロード操作を無効化する設定は用意されていない様子でした。キーボードショートカットについては機能ごとに無効化できるようですが、メニュー項目の方が利用可能なままだと、機能の無効化としては不充分です。このような場合、機能の入口である「メニュー項目」や「キーボードショートカット」を無効化する代わりに、機能の出口である「ページの再読み込み」や「印刷」の部分に介入して、「ページの再読み込みに特有の読み込みパターンを検知してブロックする」「印刷ダイアログが表示されたことを検知して、それを強制

2026年2月27日にLTS版 Fluent Package v6.0.2をリリースしました。本記事では、Fluent Package v6.0.2の変更内容を紹介します。Fluent Package v6.0.2Fluent Package v6.0.2では、以下の改善を行いました。Rubyのバージョンを3.4.8にアップデートしました同梱のFluentdをv1.19.1からv1.19.2に更新しましたrpm: tmpfiles.dによってFluentdの一時ディレクトリーが消去されてしまった状態ではアップデートに失敗する問題を修正しましたmsi: インストールがエラーで中断してしまうことがある不具合を修正しましたこの記事では、Fluent Package v6.0.2の主な変更点を詳しく解説します。変更内容の詳細Rubyのバージョンを3.4.8にアップデートRuby 3.4.8には複数のバグと脆弱性の修正が含まれています。詳細はRuby 3.4.8 リリースノート をご覧ください。同梱のFluentdをv1.19.1からv1.19.2に更新Fluentd v1.19.2では以下の修正が含まれています。設定ファイルの自動読み込みによってエラーが発生しないようにしましたin_tailで読み取り権限のないファイルを読み込ませようとしたときのエラーを修正しましたout_forward利用時に不安定なネットワーク環境下で無限ループが発生しないように修正しましたgem: IPv6アドレスのエラーを解消するため最新のnet-httpを使うようにしましたバックアップ設定ファイルが読み込まれていそうな場合に警告できるようにしました詳細については、Fluentd v1.19.2 をリリースで説明しているのでそちらを参照してください。rpm: tmpfiles.dによってFluentdの一時ディレクトリーが消去されてしまった状態でアップデートに失敗する問題を修正tmpfiles.dによって一時ディレクトリが削除されている状態で、fluent-package v6.0.0もしくはv6.0.1へアップデートしようとすると、失敗する問題があったのを修正しました。v6.0.0から入った処理に問題があったためで、更新前のバージョンに関係なく発生していました。これからFluent Package

RubyKaigi 2026の2日目の夜にアンドパッドさんが開催するコード懇親会のお手伝いをする須藤です。去年に引き続き、今年もアンドパッドさんがコード懇親会を開催してくれる予定です。去年はいくつかのテーマを事前に用意してみたのですが、よさそうな感じだったので今年も事前にテーマを用意する予定です。今年は、運営側が用意したテーマだけではなく、参加予定者から公募したテーマも1つか2つ混ぜてどうなるか試してみたいです。ということで、この記事はそのお知らせです。コード懇親会とはコード懇親会は「コードで懇親しよう！」というコンセプトのイベントです。Rubyはプログラマーの楽しさが大事なことの1つです。Rubyでプログラミングすると楽しいなら、Rubyistは（お酒とかじゃなくて）コードを中心に据えても楽しく懇親できるんじゃない！？というアイディアです。テーマコード懇親会ではテーマごとにグループを作って懇親します。たとえば、去年のテーマは以下のとおりでした。dRubyMRI (Matz Ruby Interpreter, CRuby)TRICK, Reline and IRBRubyGems/BundlerRed Data ToolsmrubyRDocOSS contributionこのうち、dRubyからmrubyまでが事前に決めたテーマで最後の2つがその場で参加者の興味を決めたテーマでした。以前はすべてその場で参加者の興味を聞いて決めていましたが、去年はいくつか事前にテーマを決めました。テーマを事前に決めることとその場で決めることで大きな違いは準備ができるかどうかです。たとえば、dRubyテーマでは既存のワークショップ資料をもとにしたアップデート版の資料を用意してそれを使っていました。事前に用意したテーマすべてで準備していたわけではありませんが、必要であれば事前に準備できるというのが違いになります。事前準備なしで、はじめましての人たちと最初はたどたどしいながらも徐々にコードを通じて懇親していくスタイルもそれはそれで面白い体験（たとえば、RubyKaigi 2024でのコード懇親会の石川さんの感想など）だと思いますが、事前準備ありならではの面白い体験もありそうです。ということで、RubyKaigi 2026でのコード懇親会でも事前にいくつかテーマを用意します！今回のテーマすで

OSS開発に参加する人を継続的に増やしていくプロジェクトOSS Gateをやっている須藤です。2026-02-13（金）にOSS Gateワークショップを東京でオフライン開催しました！会場はオプティムさんが提供してくれました！懇親会ではオプティムさんが作っているスマート米を無料で提供してもらいました。カレーライスにして食べました。おいしかったです！お米がおいしすぎてカレーの方が余ってしまいました。参加者数：22人！新型コロナウィルス以降、OSS Gateワークショップは主にオンラインで開催していたのですが、約1年ぶりにオフラインで開催することになりました。せっかくオフラインで開催するならできるだけ多くの人と一緒にやりたいと思って今回はいつもよりも告知をがんばりました。その結果、いつもは多くても10人くらいだったのに今回は22人も参加してくれました。しかも、参加登録者のうち欠席した人は1人だけでした。これまでになんどもイベントを開催してきましたが、こんなに欠席率が低いことは非常に稀です。数割の人が（連絡なく）欠席することばかりだったので非常に驚いています。もしかしたら、平日の日中に開催したからかもしれません。欠席が多いイベントは平日の夜や休日のイベントでした。イベント開催前は「平日日中で集まる？大丈夫？」という懸念もあったのですが、会場提供のオプティムさんが社内でたくさん参加者を募ってくれたり、いろいろな人に告知を手伝ってもらったりしたら20人超の参加者になりました。1/3くらいがオプティムの方でした。会場提供してくれたオプティムさんには優先的に参加してもらいたくて最初の方は告知先を絞っていました。ある程度オプティムさんからの参加者が出揃った段階で、個別に声をかけて告知を手伝ってもらいました。手伝ってくれたみなさんありがとうございます！また、@yasulabさんにはRailsガイドのコミュニティ支援の一環としてRailsガイド内で告知してもらいました。Railsガイドに協賛すると同じようにRailsガイド内で告知できるので、Railsユーザーにリーチしたい人は検討してみてください。さらに、ワークショップの様子も撮影してもらいました。実は、OSS GateのYouTubeチャンネルがあって、9年前にクラウドワークスさんに会場提供してもらったときのOSS Gateワークシ

2026年2月13日にFluentdの最新版となるv1.19.2をリリースしました。v1.19系のメンテナンスリリースとなっており、fluent-package の次期LTS版であるv6.0.2に同梱される予定です。本記事では、公式サイトで公開している情報を日本語で解説します。主な改善Fluentd v1.19.2では、いくつかの不具合を修正しました。設定ファイルの自動読み込みによってエラーが発生しないようにしましたin_tailで読み取り権限のないファイルを読み込ませようとしたときのエラーを修正しましたout_forwardで不安定なネットワーク環境下で無限ループが発生しないように修正しましたgem: IPv6アドレスのエラーを解消するため最新のnet-httpを使うようにしましたバックアップ設定ファイルが読み込まれていそうな場合に警告するようにしました以下、それぞれ解説します。設定ファイルの自動読み込みによってエラーが発生しないようにしましたFluentd v1.19.0から、特定のプラグインを組み込みで有効にできるようにする機能を搭載しました。しかし、これには副作用があり、/etc/fluent/conf.dを自動で読み込むようにしたことにより、従来該当ディレクトリ配下に設定ファイルを配置していた場合には重複して読み込んでしまっていました。これにより、Fluentd起動時にエラーが発生していました。従来の設定ファイルを変更せずそのまま使い続けたい場合には、次のようにconfig_include_dirを明示的に無効化して回避する必要がありました。<system> config_include_dir ""</system>今回のリリースでは、そのような利用条件でも起動時の設定読み込みでエラーが発生しないよう修正しました。in_tailで読み取り権限のないファイルを読み込ませようとしたときのエラーを修正しました">in_tailで読み取り権限のないファイルを読み込ませようとしたときのエラーを修正しましたLinuxのCapabilityを有効にしてログを読み込むようにしていた場合、未初期化の変数にアクセスしようとしてエラーが発生するケースがありました。今回のリリースでは、そのような場合でもエラーが発生しないように修正しています。out_forwardで不安定なネッ

Groongaの開発とサポートをしている堀本です。今年も年に一度の肉の日（2月9日のこと）が来ました。例年通り、Groongaをメジャーバージョンアップしたので、この一年でどのくらいGroongaがよくなったかを紹介します！メジャーバージョンアップなのですが、特に非互換の変更を入れていないので、いつもどおり既存のデータベースを移行せずにGroongaをアップグレードできます。GroongaGroongaは今回のメジャーバージョンアップで16.0.0になりました。前回のメジャーバージョンアップからの目玉機能は以下の通りです。セマンティックサーチのサポート踊り字の正規化対応TABLE_PAT_KEYのテーブルの最大合計キーサイズを拡張grndb checkの改良それぞれ簡単に紹介します。セマンティックサーチのサポート最近では、LLM（大規模言語モデル）を使って、検索キーワードの字面ではなく、意味に基づいた検索ができる検索エンジンが増えています。Groongaでも、LLMを使った意味ベースの検索ができるようになりました。検索の精度は使用するLLMの精度に大きく依存しますが、従来のキーワード検索と併用してより有用な検索結果を得られるケースがあります。この機能については、 PostgreSQL Conference Japan 2025でも発表してきたので、 PostgreSQL Conference Japan 2025：PostgreSQLでのセマンティックサーチへの挑戦 #pgcon25j の記事も合わせて参照してください。踊り字の正規化対応日本語には踊り字という前の文字を繰り返す記号があります。例えば、「久々」の「々」や「こゝろ」の「ゝ」が踊り字です。これらの踊り字の有無を無視して検索できるようになりました。つまり、「こころ」で「こゝろ」と「こころ」がヒットするようになります。この機能についても、 PGroongaで踊り字の有無を無視して検索する方法 に詳細がありますので、合わせて参照してください。table_pat_keyのテーブルの最大合計キーサイズを拡張">TABLE_PAT_KEYのテーブルの最大合計キーサイズを拡張非常に大きなデータも扱えるGroongaですが、制限もあります。その中の一つに、最大の合計キーサイズの制限があります。今回はこの最大の合計キーサイ

Groongaが予期せぬ理由で落ちた理由を調査中の阿部です。通常の終了処理で終了すると問題は起きないのですが、突然の停電などでGroongaサーバーが落ちると、Groongaのデータが壊れる場合があります。壊れた場合は復旧する必要があります。そんなときに役立つツールを紹介します。はじめにそのツールは以前の記事でも紹介されているgroonga-query-log gemに含まれるgroonga-query-log-check-crashコマンドです。実行すると復旧のヒントになる情報が得られます。復旧のヒントも得られるのですが、このツールが「Groongaが落ちたときに何が起きたのかを把握しやすくする」ことに重きをおいていたため、復旧を目的に使うと少々使いづらいツールでした。具体的には出力が多くて復旧のヒントになる情報を見つけにくかったのです。今回リリースした1.7.9では出力の情報を整理しつつ、Groongaに何が起きたのかを検出する精度を向上させたので、改めてgroonga-query-log-check-crashの使い方を説明します。インストールインストール方法は以前と同じです。事前にRubyをインストールします。Rubyをインストールしたら以下のコマンドでインストールできます。$ gem install groonga-query-log# ...（略）$ gem list groonga-query-log*** LOCAL GEMS ***groonga-query-log (1.7.9)1.7.9以降で改良されているので、1.7.9以降がインストールされたことを確認してください。使い方使い方も基本的に以前と同じです。プロセスログ（以前の記事で通常のログと呼ばれているもの）とクエリーログのパスを指定します。（Groongaのログについてはドキュメントでご確認ください。）すべてのログを指定します。指定する順番は気にしなくて良いです。とりあえずすべて指定すればよいです。次のようにプロセスログとクエリーログが順番になってなくても良いですし、タイムスタンプ順に並んでいなくても良いです。実行例:$ groonga-query-log-check-crash \ path/to/process-log-2000-02-* \ path/to/query-log-200

クリアコードではログデータ収集ソフトウェアの1つであるFluentdの継続的な開発に参加しています。Fluentdのコンテナイメージやエンタープライズにおける長期運用に適したLTS版のパッケージ（Fluent Package）を提供しているのもその成果の1つです。本記事では、コンテナイメージの脆弱性の有無をGitHub Actionsを活用して簡単に確認できるようにする方法について紹介します。コンテナイメージの脆弱性を確認する方法昨今ではOSSのものから商用版のものまで、多種多様な脆弱性スキャナが提供されています。OSSだとTrivyであったり、Grypeなどが有名です。脆弱性スキャンを実施するためのコンテナイメージも公開されているので、比較的利用しやすいです。例えば、RubyのコンテナをGrypeでスキャンしてみると次のような結果が得られます。$ docker run --rm anchore/grype:latest ruby:3.4-slimNAME INSTALLED FIXED IN TYPE VULNERABILITY SEVERITY EPSS RISK login.defs 1:4.17.4-2 (won't fix) deb CVE-2024-56433 Low 5.1% (89th) 1.7 passwd 1:4.17.4-2 (won't fix) deb CVE-2024-56433 Low 5.1% (89th) 1.7 tar 1.35+dfsg-3.1 deb CVE-2005-2541 Negligible 1.8% (82nd) < 0.1 libc-bin 2.41-12 deb CVE-2018-20796 Negligible 1.7% (81st) < 0.1 libc6 2.41-12 deb CVE-2018-20796 Negligible 1.7% (81st) < 0.1 apt 3.0.3 deb CVE-2011-3374 Negligible 1.5% (80th) < 0.1 ...(途中省略)...coreutils 9.7-3 deb CVE-2017-18018 Negligible < 0.1% (17th) < 0.1 bsdutils 1:2.41-5 deb CVE-2022-0563 Neg

結城です。このブログでは2018年に、Firefoxの不具合を修正したり新機能を追加したりといったコントリビューションを行う際のパッチの作り方と、Phabricatorというツールを使ってコードレビューを受ける手順を紹介しました。2026年現在では、既定のバージョン管理システムがMercurialからGitに移行した他、Phabricatorを使うためのツールのインストール手順が簡素化され、Firefoxへパッチを提供するためのハードルが以前よりも低くなっています。この記事では、Firefoxへの不具合報告の仕方の解説と不具合の原因調査および修正の仕方の解説に続くシリーズ完結編として、2026年の状況に基づいてFirefoxに不具合を修正するパッチを提供する手順をご紹介します。報告の流れ（おさらい）前々回記事・前回記事の冒頭において、オープンソース開発プロジェクトへの外部からの関わり方として以下の3段階がある旨を述べました。不具合を報告する。原因を調査して明らかにする。不具合を修正するパッチを提供する。本記事では、このうち3の部分について、2022年に筆者が実際に報告し2025年末に解決となったBug 1762249の事例を参考にして説明します。この記事では、「WindowsでのFirefoxのビルド手順の解説に従ってFirefoxのリポジトリーをローカルにcloneしていて、そのリポジトリー上で修正のための変更を行ったけれどもまだcommitはしていない」という状況から説明を始めています。「どのような不具合だったか」については前々回記事で、「どのように修正したか」は前回記事で詳しく説明しているので、背景を知りたい方はまず前々回記事からご覧下さい。修正を提案する前回記事では、自分が報告したFirefoxの不具合について、原因を突き止め、実装の修正を手元で行ってみました。実装を修正して、回帰テストも用意できたら、いよいよ修正の提案です。本稿執筆時点では、Firefoxのソースコードの中央リポジトリーはGitHub上のGitリポジトリーとなっています1。しかし、不具合の報告の受け付けにGitHubのイシュートラッカーではなくBMO（bugzilla.mozilla.org）という別の仕組みが使われているのと同様、修正提案の受け付けやコードレビューにも、GitHubのプル

結城です。このブログでは過去何度か、FirefoxやThunderbirdの不具合の原因調査や修正の事例をご紹介してきました。ですが、原因の見つけ方や修正方針の検討の詳細な所はあまり言語化してきていなかったように思われます。この記事では、Firefoxへの不具合報告の仕方の解説の続編として、Firefoxを使用していて遭遇した不具合の原因を特定し、経緯や事情を調査して適切な修正内容をまとめる所までの詳細な流れをご紹介します。報告の流れ（おさらい）前回記事の冒頭において、オープンソース開発プロジェクトへの外部からの関わり方として以下の3段階がある旨を述べました。不具合を報告する。原因を調査して明らかにする。不具合を修正するパッチを提供する。本記事では、このうち2の部分について、2022年に筆者が実際に報告し2025年末に解決となったBug 1762249の事例を参考にして説明します。「どのような不具合だったか」については前回記事で詳しく説明しているので、この記事から読もうとしている方は、まず前回記事からご覧下さい。不具合の原因箇所を特定する前回記事で詳述しましたが、この事例では、問題の発生時にFirefoxがJavaScriptの例外を投げています。端的には、この例外の出所がまさに「修正が必要な箇所」と言えます。ただ、今回発生している例外はアドオンからは「Error: An unexpected error occurred（エラー：予期しないエラーが発生しました）」という抽象的なメッセージを伴った物としてしか捕捉できていません。about:debugging から開けるアドオン用のデバッグツールのコンソールで▸をクリックしてログを展開しても、例外がセキュリティ境界をまたいで通知されている1せいで、スタックトレースは得られていません。このような場合、Firefox本体のエラーコンソール（Ctrl-Shift-J）でヒントを得られることがあります。FirefoxのWebExtensions APIはほぼすべてJavaScriptで実装されており、Firefox自体のデバッグツールであれば、Firefox内で生じた例外の詳細な情報を閲覧できます。今回の事例でも、Firefoxのエラーコンソールにはスタックトレースを伴った例外の情報が出力されていました2。Failed to

結城です。Firefoxを開発しているMozillaプロジェクトでは、ソースコードのバージョン管理システムをMercurialからGitに移行し、GitHubでホスティングしていく方針が2023年に示されました。その後、実際に移行が進んで、本稿執筆時点（2026年1月）ではソースコードの入手はGitHubのリポジトリーから行うのが規定となっています。その一方で、不具合報告の受け付け・管理のためのイシュートラッカーとしては、GitHubのイシュートラッカーではなく、Mozillaプロジェクト専用のイシュートラッカーであるbugzilla.mozilla.org（以下、BMO）が依然使われています1。このブログでは、Firefoxの不具合を修正したり新機能を追加したりといったコントリビューションを行う際のパッチの作り方を2018年に紹介しましたが、当時の記事は既に誰かによって報告された不具合へのパッチ提出が前提で、自分が見つけた不具合を報告する場面の説明は含まれていませんでした。パッチ提出の流れには当時と比べ変化があったため、その点を紹介する記事を執筆したいのですが、まずはその前段階として、この記事では具体的な事例を参照しつつ、BMOを用いたFirefoxの不具合報告の仕方をご紹介します。報告の流れ一般的に、コントリビューションを広く募っているオープンソース開発プロジェクトでは、プロジェクト外の人がソフトウェアの不具合に遭遇したときに、プロジェクトの問題を解決する方法として以下の3段階の関わり方が可能です。不具合を報告する。原因を調査して明らかにする。不具合を修正するパッチを提供する。本記事では、このうち1の部分について、2022年2に筆者が実際に報告したBug 1762249の事例を参考にして説明します。報告したい問題の詳細を明らかにする多くの場合、ソフトウェアを使っていて問題に遭遇したときには、まず「変だ！」「動かない！」「困った！」と感じるものでしょう。ただ、それをそのまま「なんか変なんだけど！」とだけ報告しても、解決には繋がりません。解決に繋がるように報告するためには、「自分が遭遇した問題がどういう問題なのか」を自分で調べて明らかにして、ソフトウェアの開発者の側でも把握できるように説明する必要があります。Bug 1762249の時は、筆者が作成したFirefox

ソフトウェアエンジニアの阿部です。最近、OpenArmというハードウェアに触る機会があったので、それに関連する記事です。OpenArmはロボットアームです。公式サイトに動画もあるのでご覧いただければどのようなモノかすぐにわかると思います。実物が手元にあっていろいろいじれるととても楽しいと思うのですが、今のところ実物が手元にないのでROS2というものでシミュレーションしてOpenArmに触れあってみた記録です。対象読者私はソフトウェアエンジニアでハードウェアのことはまったく経験なしです。普段パソコンは使うので、CPUとかメモリとかくらいの部品は知っていますが、ロボットアームやそれを構成している金属部品、モーターについてはまったく経験なしです。そんなスキルセットの私の経験談の記事なので、ソフトウェアエンジニアでLinuxの基本的な操作はできつつ、ロボットアームについては何も知らないけど興味はある！という方の参考になると思います。はじめにOpenArmはオープンソースのロボットアームです。操作するためのソフトウェアに加えて、ロボットアームを構成する部品の設計もすべて公開されています。各リポジトリ: https://github.com/enactic/openarm私はいろいろ触れ合ったので、ある程度用語の意味がわかりますが、ロボットアームの経験がない方は初見の用語が多くて親しみにくいかもしれません。本記事はすべてを理解するための解説記事ではなく、「とりあえずシミュレーションが動く」を体験することを目的にするので、用語の説明は最低限にとどめます。説明の足りないところがあるかもしれませんが、その点はご了承ください。ロボットアーム関連の用語ROS2ROSはRobot Operating Systemの略です。今回の記事を読む上では「ROS2」は「ロボットを制御するときに使う便利なソフトウェア」くらいの理解で大丈夫です。参考: https://docs.ros.org/en/kilted/index.htmlMoveIt2「MoveIt2」はROS2上で動くロボットアームの動作計画などの作成を支援するフレームワークです。ロボットアームを上げて下げる、とか一連の流れを便利に作れます。ROS2をOSとすると、MoveIt2はその上で動く便利ソフトという位置付けです。参考: http

OSS開発に参加する人を継続的に増やしていくプロジェクトOSS Gateをやっている須藤です。2026-02-13（金）にOSS Gateワークショップを東京でオフライン開催することになったのでそのお知らせです！オフライン開催OSS Gateでは「まだOSSの開発に参加したことがない人」向けのワークショップも開催しています。前はオフラインで開催していたのですが、新型コロナウィルス以降はオンライン開催が主流になりました。一般的に、オンライン開催は地域を問わずに参加できるというメリットがありますが、オフライン開催に比べて人と人のつながりを強めにくい傾向があるようです。OSS Gateでは、「まだOSSの開発に参加したことがない人」が「参加したことがある人」になって、その人が新しい「まだOSSの開発に参加したことがない人」をサポートして「参加したことがある人」にして、というようにOSS Gateに関わる人も増えることでより多くの「OSS開発に参加する人」を継続的に増やしていきたいと思っています。そのため、一度参加した人のうちできるだけ多くの人がなんらかの形で継続的にOSS Gateに関わって欲しいです。オフライン開催がその助けになるといいなぁと思って東京でオフライン開催をすることにしました。会場提供はオプティムさんオフライン開催をするには会場が必要なのですが、今回はオプティムさんが提供してくれることになりました。オプティムさんとはcsv gemのissueで知り合いました。詳細はオプティムさんのブログを読んでもらうとして、これがきっかけでRailsTokyo #1【ブルーモ証券：みんなの投資から学べる本格米国株資産運用】で声をかけてもらいました。話を聞いたところ、社内の開発者が、自分たちが使っているOSSの開発に自分たちのアプリケーションと同じように参加する組織にしていきたいということでした。クリアコードはOSS開発支援サービスとしてそのような組織を有償でサポートするサービスも提供していますが、会場を提供してくれて社外の人も参加可にしてくれるならOSS Gateワークショップを無償で開催しますよ！と提案しました。ということで、（オプティムのみなさんを優先的に参加できるようにしますが）それ以外の人も参加できます！平日開催また、今回は「平日」に開催することにしました。いつもは

結城です。このブログではこれまで、2015年と2017年にWindowsでのFirefoxの独自ビルドの作成方法をご紹介しました。本稿執筆時点では、既定のバージョン管理システムがMercurialからGitに移行していたり、MozillaBuildやブートストラップスクリプトによる自動初期化の仕組みが進歩していたりして、また状況が変わっています。この記事では、2026年1月現在においてWindows用のNightlyおよびFirefox ESR140の独自ビルドを作成する手順をご紹介します。はじめにこの記事では話を簡単にするために、Firefoxの動作の解析のためにログ出力を増やしたり、Firefoxの不具合を修正するためのパッチの有効性を実際の動作で確認したりといった、開発や検証を目的とする場合を想定することにします。また、Firefoxの法人向けサポートサービスを提供している当社においては、Firefox ESR版の運用時に遭遇したトラブルについて、原因調査や回避策の検討のためにデバッグ用ビルドを顧客環境で実行して頂く場合があるため、最終的にはその範囲にも言及します。この記事では以下の3段階に分けて、それぞれのビルド手順を順番に解説していきます。英語版Nightly Artifact Modeビルド（HTML/XML、JavaScript、CSSなどで実装されている箇所の変更の検証、または、それらの箇所へのログ出力追加による詳細なデバッグ用）英語版Nightly フルビルド（C++、Rustなどで実装されている箇所の変更の検証、または、それらの箇所へのログ出力追加による詳細なデバッグ用）日本語版Firefox ESR140 フルビルド（日本語版を常用している顧客の環境でのデバッグ用）情報のありかFirefoxのビルドに関する情報は、本稿執筆時点ではFirefox Source DocsというサイトのGetting Set Up To Work On The Firefox Codebaseというセクションから辿ることができます。Windowsでのビルドなら、Building Firefox On Windowsを見ることになります1。基本的には、このオフィシャルの情報のとおりにやればつつがなくFirefoxをビルドできます。本記事では、オフィシャルの情報ではカバ