ファーエンドテクノロジー株式会社コーポレートブログ

コードから学ぶ意思決定：ポーカーで考える確率の話

2026-04-08T00:00:00Z

ポーカーの勝率はシミュレーションなどで計算され、それをもとに意思決定が行われている
判断は「今勝てるか」ではなく「長期的に得か」で考えられる
コードを通じて、“運”の中にもロジックがあることに気づいた

呂です。2年前から、友人に教えてもらったのをきっかけに、ポーカーを遊ぶようになりました。

ポーカーは、プレイヤー同士でチップを賭けながら、より強い手を作るか、相手を降ろすことで勝敗を決めるゲームです。カード運の要素もありますが、ベットやフォールドといった判断によって結果が大きく変わるのが特徴です。最近では、日本でも競技としてのポーカーを目にする機会が増えてきたように感じます。

参考：https://ja.wikipedia.org/wiki/ポーカー

最初はボードゲームの延長のような感覚で、あまり深く考えずに遊んでいました。ただ、プレイを重ねるうちに、思っていた以上に“考えること”が多いゲームだと感じるようになりました。

そこで気になったのが、「この判断はどう決まっているのか？」という点です。ポーカーでは、フォールド・コール・ベットといった選択を常に求められます。こうした判断の中でよく出てくるのが「equity（勝率）」という概念です。ただ、ここで一つ疑問が出てきました。

この“勝率”って、どうやって計算されているのか？

本記事ではポーカーそのものの面白さを紹介するというよりも、練習アプリのコードをきっかけに、「意思決定の仕組み」や「確率の考え方」について整理してみたいと思います。

1. コードの中の「勝率」

例えば、PyPokerEngine のサンプルコードでは、次のように勝率が使われています。PyPokerEngineはPythonで手軽にポーカーAIを組めるライブラリです。

# examples/players/honest_player.py

win_rate = estimate_hole_card_win_rate(
    nb_simulation=1000,
    nb_player=self.nb_player,
    hole_card=gen_cards(hole_card),
    community_card=gen_cards(community_card)
)

if win_rate >= 1.0 / self.nb_player:
    action = valid_actions[1]  # call
else:
    action = valid_actions[0]  # fold

出典： https://github.com/ishikota/PyPokerEngine

このコードでは、

まず勝率（win_rate）を計算する
その値が「平均的な勝率（1 / プレイヤー数）」以上かどうかで判断する

という、とてもシンプルなロジックになっています。つまり、

勝率を求めて、それを基準に行動を決めている

という構造が、そのままコードとして表現されています。

2. 勝率はどうやって計算されているのか

では、この win_rate はどのように求められているのでしょうか。コードを追っていくと、意外なことが分かります。この勝率は、数式で一発計算されているわけではありません。代わりにやっているのは、かなりシンプルな処理です。

やっていること

すでに見えているカードを固定する
残りのカードからランダムにカードを引く
相手の手札もランダムに決める
最後まで配って勝敗を判定する
これを何度も繰り返す

つまり、

「もしこの状況を何回も繰り返したら、どれくらい勝つか？」

を実際に試している、ということです。

3. カードの枚数ベースで考える

例えば：

自分の手札：2枚
フロップ：3枚

この時点で、すでに5枚のカードが見えています。トランプは全部で52枚なので、残りの未知カードは52 - 5 = 47枚です。

この47枚の中から、

ターン
リバー
相手の手札

が決まります。

本来であれば、この47枚から考えられるすべての組み合わせを列挙すれば、完全な勝率を計算することができます。

4. でも、全部は計算しない

ただし、組み合わせは非常に多くなります。そのため、PyPokerEngine では次のような方法を取っています。

すべてを計算するのではなく、ランダムに何度も試す

これが「モンテカルロ法」と呼ばれる方法です。

例えば：

1000回シミュレーションする
そのうち600回勝つ

この場合、

勝率 ≒ 600 / 1000 = 0.6

となります。

調べてみると、勝率の計算は必ずしもランダムなシミュレーションだけで行われているわけではなく、残りのカードのすべての組み合わせを列挙して、正確に求める方法もあるようでした。実際に PokerStove のようなツールでは、こうした組み合わせベースの計算によって、高い精度で勝率を算出できるとのことです。PokerStoveは数学的なアプローチで、膨大な組み合わせの中から正確な勝率（Equity）を導き出すためのツールです。

出典：https://github.com/andrewprock/pokerstove

ただし、この方法は計算量が非常に大きくなるため、状況によっては現実的ではありません。そのため、PokerStove を含む一部のツールでは、全探索ではなくモンテカルロ法による近似計算を選択できる場合もあるようです。

5. equityと意思決定、そしてAIへ

ここまでを見ると、equityの正体はかなりシンプルです。

「今の情報を固定して、未来をランダムに埋めたときの勝率」

です。

この勝率は、それ自体がゴールではなく、あくまで「意思決定の材料」として使われます。例えば、次のような形です。

if equity > 0.6:
    raise

→ 勝率が60%以上なら強く出る

if EV > 0:
    call

→ 長期的に得ならコールする

ここで重要なのは、「今勝てるか」ではなく「繰り返したときに得か」で判断している点です。つまり、1回の結果ではなく、同じ状況を何度も繰り返したときにどうなるか、という視点で行動が決まっています。勝率（equity）はそのための入力値であり、最終的な判断は期待値（EV）という形で整理されます。

最近では、AIを使った高度な戦略が一般的になっていますが、コードを見て感じたのは、その出発点は非常にシンプルだということでした。

勝率を求める
条件で分岐する

この基本構造は、人間が考えるときのロジックとも大きくは変わりません。AIはこの仕組みをより大量のデータと計算によって繰り返し、精度を高め、戦略として最適化していったものとも言えます。つまり、複雑に見えるAIの判断も、その根底には「確率をもとに意思決定する」というシンプルな構造がある、ということが見えてきます。

6. コードから学ぶということ

正直に言うと、私はまだポーカーに慣れているわけではありません。何を基準に判断すればいいのか、はっきりとした軸を持てているとも言えません。そんな中で見つけたのが、「コードから考える」という方法でした。ポーカーのロジックをコードで見ていくと、そこには感覚ではなく、確率や条件として整理された判断の仕組みがあります。

少し個人的な話になりますが、私は文系出身です。数学がまったく苦手というわけではなく、関数や図形はむしろ好きな方でした。ただ一つ、どうしても苦手意識があったのが「確率」です。どこか曖昧で、つかみどころがなく、ポーカーも「運のゲーム」として距離を置いていました。

ですが、コードとしてロジックを見るようになってから、その裏にある考え方が少しずつ見えるようになってきました。まだ完全に理解できたわけではありませんが、少なくとも「運」で片付けていたものの中に、考える余地があることには気づけた気がします。ポーカーは、直感だけでも、理論だけでも成立しないゲームです。だからこそ、まずはロジックから考えてみる。そして少しずつ、自分なりの判断を積み重ねていく。そのプロセス自体が、このゲームの面白さなのかもしれません。

【スタッフ募集中】
「My Redmine」など弊社提供サービスのお問い合わせ対応を担当するカスタマーサポートスタッフを募集しています。
弊社での勤務に関心をお持ちの方は、知り合いの弊社社員・関係者を通じてご連絡ください。採用情報の詳細

こちらの記事もオススメです！

	データベーススペシャリスト試験合格と学習の振り返り令和7年度秋期のデータベーススペシャリスト試験に合格し、過去問題を通じて自分の理解の曖昧さや苦手分野を可視化できました。
	AIを活用してテキストエディタ「Textbringer」のプラグインを作った話テキストエディタ「Textbringer」の機能を拡張するプラグインをClaude Codeで作りました。
	Redmineの通知メールをプロジェクトごとに自動で振り分ける（Gmail） Redmine 6.0では通知メールの「List-Id」ヘッダにプロジェクト識別子が含まれるようになりました。Gmailで通知メールをプロジェクトごとに自動振り分けする方法を紹介します。
	p5.rbでGenuary 2026に参加してみた Genuary 2026をきっかけに、p5.rbで初めてジェネラティブアート制作に挑戦しました。
	Redmineで働き方を再定義 -OSC2026 Osaka & Tokyo/Spring 出展を通して考えたこと- OSC2026 OsakaとTokyo/Spring の出展を通して、Redmineの運用がうまくいくチームとそうでないチームの違いについて改めて考えてみました。

データベーススペシャリスト試験合格と学習の振り返り

2026-04-02T00:00:00Z

令和7年度秋期のデータベーススペシャリスト試験に合格し、過去問題を通じて自分の理解の曖昧さや苦手分野を可視化できました
実際に使った教材、学習を継続する工夫、本番での問題選択と振り返りまで、再現しやすい形でまとめています
学習では、まず午後Iを通過することを重視し、問題選択の基準づくりを進めました

前田稔です。令和7年度秋期のデータベーススペシャリスト試験に合格しました。この記事では、受験した背景、学習方針、実際に取り組んだこと、使った教材を振り返ります。

IPAによると、データベーススペシャリスト試験は、データ資源管理やデータベース基盤の企画・要件定義・開発・運用・保守で中心的な役割を担う人を主な対象としています。

受験した背景

受験のきっかけは二つありました。一つは、社内でIPA試験に取り組んでいる方々がいらしたので、その姿勢に刺激を受けたことです。もう一つは、受験者層です。受験を考え始めた頃に見ていた IPAの統計情報では、令和6年度秋期のデータベーススペシャリスト試験の受験者平均年齢は35.3歳でした。自分の年代と近く、受験を考えるきっかけになりました。

受験してよかったこと

今回の受験でよかったのは、自分の理解を見直す機会になったことです。学習を通じて、知っていること、理解していること、人に説明できることは、それぞれ別だと改めて感じました。過去問題では、用語を知っているだけでは対応しにくく、問われている内容の関係や前提条件を踏まえて説明できるかが問われます。そのため、自分の理解が曖昧な部分がはっきりし、苦手分野を整理して学び直すことができました。

また、過去問題の事例には、概念データモデリング、業務要件の整理、設計判断など、実務にもつながる観点が多くありました。その点でも、学習そのものに意味があったと感じています。

学習方針

学習期間は約3ヶ月で、主に過去問題を中心に取り組みました。学習方針としては、まず午後Iを安定して通過できる状態を作ることを重視しました。そのためにIPAの統計情報(リンク先は国立国会図書館のアーカイブ)を活用しました。

令和6年度秋期のデータベーススペシャリスト試験は、受験者10,120名、合格者1,744名で、合格率は17.2%です。午後I試験通過者（得点が60点以上）は3,247名なので、令和6年度秋期では、午後I通過者のうち最終合格者の割合は約54%でした。こうした数字を踏まえると、まず午後Iを通過できる状態を作ることが、自分にとって現実的な目標だと考えました。

午後Iでは、知識そのものだけでなく、制限時間の中で問題を選び、何が問われているかを見極め、問いの構造や関係性を整理したうえで解答する力が重要だと考えていました。そのため、単に知識を増やすのではなく、午後Iで問われる内容に答えられる状態を作ることを意識しました。

実際の学習内容

午前I対策

午前Iは、応用情報技術者試験の範囲を広く浅く押さえる方針で進めました。

学習には主に応用情報技術者試験の過去問道場を使いました。問題を解き、解説を読み、疑問があれば検索したりAIに確認したりして理解を補っていました。高得点を狙うというより、まず確実に通過することを優先していました。

私の場合は、主に昼休みなどのスキマ時間に取り組んでいました。出題範囲が広いため、本来はもう少し時間をかけてもよかったと思っています。計算問題は最後まで苦手意識がありましたが、少なくとも解き方を思い出せる程度には、過去問題を繰り返しておいた方がよいと感じました。

午前II対策

午前II対策では、後述する『情報処理教科書データベーススペシャリスト』の購入者特典を活用しました。午前IIの過去問題が重複を除いた形で整理されており、書籍の流れに沿って取り組みやすかったためです。

午後I・午後II対策

午後I・午後IIは、基本的に過去問題を中心に学習しました。

過去問題を解くと、自分の苦手分野と出題傾向が見えてきます。そのため、本番でどの問題を選ぶかの基準も作りやすくなりました。

たとえば、データベースの物理設計は、問われ方や計算の型が比較的はっきりしていて、対策しやすい分野だと感じました。一方で、概念データモデリングや業務要件の読解は、知識だけでなく整理力や判断力も必要で、重点的に練習する必要があると考えました。

また、午後Iは、午後IIで求められる考え方を、より限定された条件の中で問う問題だと感じていました。午後IIに比べると、必要な情報を整理しやすく、基礎知識や典型的な考え方で対応しやすい印象でした。

学習を続けるために工夫したこと

学習では、一度に長時間進めるより、日常の中で続けやすい形を作ることを重視しました。

たとえば、ブラウザ起動時に過去問道場を開くようにして、すぐ問題に触れられる状態を作っていました。また、1日に午前問題を1問だけ解く日があってもよいと割り切り、少しでも続けることを優先していました。また、当社が毎月開催しているオライリー本の全冊公開日やもくもく勉強会のような場も、学習ペースを保つうえで役立ちました。

受験前に整理していた方針

受験前には、本番での問題選択や読み方、解答の進め方についても、自分なりの方針を整理していました。

問題選択では、知識の有無だけでなく、自分が読み違えやすいタイプの問題を避けることも意識していました。たとえば、「出庫」や「出荷」のように似た用語が複数出てくる問題は、午後の時間帯には疲れもあり、前提条件の見落としや候補キーの洗い出しでミスが出やすいと考えていました。そのため、こうした問題は意識して避ける対象にしていました。加えて、業務知識が十分でない分野の問題（定期発注・定量発注など）も避けるようにしていました。

問題文は、まず見出しで全体の構造を見て、次に設問を読み問われていることを確認し、表や図を確認して、文章以外の情報を取得してから本文に入る、という順序を意識していました。解答するときは、まず根拠になる記述や表を探し、必要な情報を先に押さえるようにしていました。時間が厳しいときも空欄を減らせるように意識し、部分点を意識して書けることは書く方針にしていました。

試験当日を振り返って

午前I

試験当日は、午前Iを解き終えた時点では、手応えはあまりよくありませんでした。

結果は気になりましたが、そこで気持ちを切らさず、まずは全ての試験を受け切ることを優先しました。実際、午前Iは64.60点でかなりぎりぎりだったため、もう少し復習しておけば不安は減ったと思います。

午前II

一方で、午前IIは88.00点、午後Iは83点で、重点的に取り組んだ領域は得点につながったと感じています。

午後Iは、もともと制限時間が厳しいと考えていましたが、本番では集中して取り組むことができました。過去問題を通じて身につけた問題選択の基準や、問われている内容を整理する感覚が機能したと思います。

午後I

午後Iは問1〜3から2問選択して解答します。

午後Iでは、問2と問3を選択しました。問2は、化学メーカーの販売営業システムを題材に、関数従属性や正規化理論を用いたデータモデル分析、業務要件に基づくデータベース設計を問う問題でした。問3は、オフィスじゅう器メーカーの在庫管理システムを題材に、SQLの設計やトランザクションの排他制御を問う問題でした。2問とも基礎的な内容をもとに解答しやすいと判断して選びました。結果として、この問題選択は得点につながったと考えています。

午後II

午後IIは問1〜2から1問選択して解答します。

午後IIでは、問2を選択しました。問2は、宅配ピザチェーンにおける店舗への資材配送業務を題材に、与えられた状況から概念データモデリングを行う問題でした。本来は、「出庫」や「出荷」のように似た用語が複数出てくる問題は避けたいと考えていましたが、問1よりは解答しやすいと判断しました。一方、問1は、コード決済事業者のコード決済システムを題材に、データベースの実装・運用を問う問題でした。決済処理方式の説明があり、自分には業務知識が十分ではなく、準備してきた解き方を活かしにくいと判断しました。

結果として、午後IIは67点でした。合格点は超えましたが、余裕があったとは言いにくく、午後IIの問題選択はやや消極的であり、その点は今後の課題として残ったと考えています。

使用した教材

学習に使った主な書籍は情報処理教科書データベーススペシャリストとデータベーススペシャリスト「専門知識＋午後問題」の重点対策です。

情報処理教科書データベーススペシャリスト

『情報処理教科書データベーススペシャリスト』は、午前問題集として有用だっただけでなく、午後IにおけるSQLなどの出題傾向の把握や、午後Iと午後IIで問われ方がどう異なるかを整理するうえでも役立ちました。辞書的な使い方もしやすく、曖昧だった内容を引き直す際にも重宝しました。実際の業務や設計の背景を理解するうえで参考になる説明もあり、業務知識を補うのにも役立ちました。

また、購入者特典の過去問題解説も有用でした。過去問題は、解いた後にどう振り返るかが大事ですが、この解説は復習の観点を整理しやすく、理解が曖昧なところを確認するのに役立ちました。

加えて、『ITエンジニアのための【業務知識】がわかる本』も参考にしました。試験対策そのものというより、業務の流れや前提知識をつかむのに役立ちました。なお、これら2冊は同じ著者による書籍であり、その著者によるYouTube動画も、受験時の考え方や時間配分、問題への向き合い方を整理するうえで参考になりました。

データベーススペシャリスト「専門知識＋午後問題」の重点対策

『データベーススペシャリスト「専門知識＋午後問題」の重点対策』は、午後I・午後IIで何が問われるのか、どのような観点で考えるべきかを整理するのに役立ちました。特に、午後I突破を重視していた自分にとっては、問題の見方をつかむうえで参考になりました。

書籍以外に参考にしたもの

学習では、試験対策本や過去問題に加えて、RDBMSの内部実装、トランザクション制御、MVCC、索引設計、性能改善、バックアップ、障害対応などに関する技術記事や発表資料も参考にしていました。すべてを深く読むというより、試験で気になった点が出てきたときに、背景や実装イメージを補うために見る使い方でした。

また、日本PostgreSQLユーザ会の動画や過去のライブ配信も活用しました。特にリストア、復旧といった分野は、文章だけで理解するより、処理の流れを追いながら説明を聞く方が理解しやすく、学習の助けになりました。

合格を振り返って

今回の受験で得られたのは、資格そのものだけではありません。自分の理解の曖昧さを可視化し、それを整理して補強する機会になったことが大きかったと感じています。

また、試験に合格したことで、少なくともIPA試験の受験者集団の中で一定水準に達していることを、一つの形として示せたとも考えています。もちろん、資格だけで実務能力のすべてを示せるわけではありませんが、学習の結果を外部に伝える材料にはなったと思います。

最終的には、過去問題を中心に学習したことが合格につながったと思います。ただ、それだけでなく、日頃の業務で受けたフィードバックや、仕事を通じて得た視点、周囲の方とのやり取りの積み重ねも、試験中の判断や理解の土台になっていたと感じています。

おわりに

今回の受験は、資格取得だけでなく、自分の理解を点検し、学び直す機会にもなりました。試験方式はペーパー方式からCBT方式に変わっていく予定ですが、過去問題を通じて苦手を見つけ、午後Iで求められる力を意識して学習を組み立てる考え方は、今後も有効だと思っています。

これから受験を検討される方の参考になれば幸いです。

参考にした情報の一部

こちらの記事もオススメです！

	AWS認定ソリューションアーキテクト - アソシエイトを受験した話 AWS認定ソリューションアーキテクト–アソシエイト（SAA‑C03）を受験し合格しました。「具体 → 抽象 → 応用」の3ステップ学習で活用した教材を紹介。
	AIを活用してテキストエディタ「Textbringer」のプラグインを作った話テキストエディタ「Textbringer」の機能を拡張するプラグインをClaude Codeで作りました。
	Redmineの通知メールをプロジェクトごとに自動で振り分ける（Gmail） Redmine 6.0では通知メールの「List-Id」ヘッダにプロジェクト識別子が含まれるようになりました。Gmailで通知メールをプロジェクトごとに自動振り分けする方法を紹介します。
	p5.rbでGenuary 2026に参加してみた Genuary 2026をきっかけに、p5.rbで初めてジェネラティブアート制作に挑戦しました。
	Redmineで働き方を再定義 -OSC2026 Osaka & Tokyo/Spring 出展を通して考えたこと- OSC2026 OsakaとTokyo/Spring の出展を通して、Redmineの運用がうまくいくチームとそうでないチームの違いについて改めて考えてみました。

AIを活用してテキストエディタ「Textbringer」のプラグインを作った話

2026-03-25T00:00:00Z

TextbringerはRubyで実装されたEmacsライクなテキストエディタです
AIを活用してTextbringerの機能を拡張するプラグインを作りました
作れなかったものが作れるようになる良い時代になったと感じています

黒谷です。今回はAIを活用してTextbringerのプラグインを作った話です。もちろんこの原稿もTextbringerを使って書きました。

Textbringerとは

TextbringerはRubyで実装されたEmacsライクなテキストエディタです。 Rubyのコミッターである前田修吾さんが開発されました。

shugo/textbringer: An Emacs-like text editor written in Ruby

私は普段から仕事でもプライベートでもTextbringerを使っています。TextbringerはRubyで拡張できるので、使いなれたRubyで気軽に便利な機能を追加することができる...と書きたいところですが、ソフトウェア開発者ではない私には大きな機能追加は難しいです。ちょっとしたコマンドを追加する程度のことはできましたが、それ以上のことはできませんでした。

AIの活用

近年AIがどんどん高性能になり、バイブコーディングという言葉も出現し、素人でもソフトウェア開発ができるようになりました。AIを活用すれば、私でもTextbringerの機能追加ができるのではないかと思い、あったらいいなと思う機能を作ってみることにしました。Textbringerにプラグインのしくみがあることは知っていたので、プラグインとして作ることにしました。

使用したのはClaude Codeです。他と比較したわけではなく、まずClaude Codeから試してみようかなという気分で採用しました。

最初は、欲しい機能をAIに伝えるところから始めました。Developers Summit 2026 参加レポート(当社ブログ記事)で「スペック駆動開発（SDD）」という言葉が紹介されていました。そこまできちんと仕様を整えたわけではありませんが、Emacsに似ている機能があれば「Emacsの○○という機能と同じような機能を実現したい」みたいにできるだけ具体的に伝えるようにしました。また、複数の機能を同時に作ることがないように、作る機能がひとつになるように気をつけました。

少しずつ機能を追加していく中でソースコードの改善が必要になったとき、ソースコードを修正してすぐコミットしようとすることがありました。ソースコードの修正差分を見ても善し悪しが判断できないため、私が判断するための根拠となるものと、改修プランを示してもらい、議論してから修正案を示してもらうことにしました。CLAUDE.mdに以下のような指示を入れています。

* ソースコードの改修案を提示するときは、根拠となる事実(修正されたコミットがどれか、等)を示してから、改修プランを示し、ユーザーと議論をしてから、提示する。

テストコードについては、Textbringerに含まれるテストコードをAIに見てもらい、それを参考にしてテストコードを書いてもらうようにしました。勉強していない私には書けないので大変助かります。

私は議論した内容を忘れるので、作業を終えるときに議論した内容や実施した内容の概要をテキストファイルに保存することにしました。Claude Codeは過去に終了した状態から再開するコマンドがありますのでそれを活用すれば良いのですが、過去の記録をさっと見返したいときにテキストファイルがあると良いなと思ったのでそのようにしています。

作ったプラグインの紹介

textbringer-minibuffer-extension

Textbringerではファイルの操作をするときなどにミニバッファを使います。このミニバッファの操作が便利になるといいなと思って作りました。

ミニバッファで選択したファイル名/バッファ名/コマンド名を記憶しておき、履歴として利用できる
zshの補完機能のように、TABを押し続けると選択肢を順番に変えていく

普段 zsh を使っており、TABを押すだけで選択肢を次から次へ変えてくれる挙動になれてしまいました。Textbringerでも同じようにしたいと思って作りました。

Gemとして登録したので、

gem install textbringer-minibuffer-extension

でインストールできます。

ソースコードは以下のリポジトリから取得できます。

https://github.com/kurod1492/textbringer-minibuffer-extension

textbringer-recentf

EmacsにはRecentfというモードがあります。このモードを有効にすると、開いたファイルのファイル名を保存しておき、あとから参照できるようになります。Textbringerを使う前、Emacsを使っていた頃はこの機能を便利に使っていました。Textbringerでも同様の機能があるといいなと思って作ってみました。

保存されたファイル名のリストをミニバッファで選択することになるため、textbringer-minibuffer-extensionがないと使いにくいと考え、依存関係が設定してあります。

Gemとして登録したので、

gem install textbringer-recentf

でインストールできます。

ソースコードは以下のリポジトリから取得できます。

https://github.com/kurod1492/textbringer-recentf

まとめ

AIを活用してTextbringerのプラグインを作ってみたというお話でした。他の人が実現してくれるのを待つのではなく、AIの力を借りて自分で作ることができる良い時代になったと感じています。

こちらの記事もオススメです！

	Redmineの通知メールをプロジェクトごとに自動で振り分ける（Gmail） Redmine 6.0では通知メールの「List-Id」ヘッダにプロジェクト識別子が含まれるようになりました。Gmailで通知メールをプロジェクトごとに自動振り分けする方法を紹介します。
	p5.rbでGenuary 2026に参加してみた Genuary 2026をきっかけに、p5.rbで初めてジェネラティブアート制作に挑戦しました。
	Redmineで働き方を再定義 -OSC2026 Osaka & Tokyo/Spring 出展を通して考えたこと- OSC2026 OsakaとTokyo/Spring の出展を通して、Redmineの運用がうまくいくチームとそうでないチームの違いについて改めて考えてみました。
	Developers Summit 2026 参加レポート Developers Summit 2026に参加しました。刺激的なセッションの数々を振り返ります。
	ファーエンドテクノロジーに入社しましたファーエンドテクノロジーに入社しました。メールからSlackとRedmineの環境に変わって快適になりました。

Redmineの通知メールをプロジェクトごとに自動で振り分ける（Gmail）

2026-03-18T00:00:00Z

Redmine 6.0より、通知メールの「List-Id」ヘッダにプロジェクト識別子が含まれるようになりました
Gmailの検索演算子「list:」を使い、特定のプロジェクトのメールを検索できます
フィルタとラベルを設定することで、通知メールをプロジェクトごとに自動で振り分けることができます

杠です。Redmineを使用していると、プロジェクトが増えるにつれて通知メールも多くなってきます。毎日届くたくさんのメールを、一通ずつ見て判断するのは意外と大変なものです。

そこで便利なのが、メールヘッダの情報を利用した自動振り分けです。今回は、Gmailを例に、通知メールをプロジェクトごとに自動で振り分けるための設定を紹介します。

Redmineのメールヘッダ

Redmineの通知メールには、振り分けに利用できるさまざまなヘッダが用意されています。

参考：Redmineの通知メールに含まれるヘッダフィールド

X-Redmine-Project の識別子からプロジェクトを判別できますが、メールサービスによってはこのヘッダを振り分け条件に使えないことがあります。しかし、Redmine 6.0 から「List-Id」ヘッダにプロジェクト識別子が入るようになり、Gmailでプロジェクトごとの振り分けが簡単に行えるようになりました。

Redmine 6.0 新機能紹介: Redmineから届く通知メールをプロジェクトごとに振り分けできるように List-Id ヘッダーにプロジェクト識別子を追加

Gmailでヘッダを確認する方法

対象の通知メールを開く
右上の「︙」メニューをクリック
「原文を表示」を選択

表示されたテキストの中から List-Id: と書かれた行を見つけます。

Gmailでヘッダを使ってプロジェクトごとにメールを振り分ける

Gmailでは、検索演算子が用意されています。プロジェクトごとにメールを振り分ける際は、先ほど確認したヘッダ情報をもとに、list: という演算子を使用します。

例： list:support-center.redmine.example.com

まずはこの文字列をGmailの検索窓に入力し、対象のメールが検索結果に表示されるかを確認します。

フィルタの作成手順

問題なく表示されたら、以下の手順で自動振り分けを設定します。

検索窓右側のアイコン（検索オプションを表示）をクリック
「フィルタを作成」をクリック
「受信トレイをスキップ(アーカイブする)」にチェックを入れる
「ラベルを付ける」にチェックを入れて、既存のラベルを選択するか新しいラベルを作成する
「フィルタを作成」をクリック

「◯件の一致するスレッドにもフィルタを適用する。」にチェックを入れると過去のメールにもフィルタが適用できます

これで、特定のプロジェクトの通知メールがラベルごとに自動的に振り分けられるようになります。

以前は、「一番に目を通したいプロジェクトの通知」と、「別に時間を取って確認したいプロジェクトの通知」、その他のメールすべてが受信トレイに混在している状態でした。

現在は、これらのプロジェクトの通知が自動で振り分けられるよう設定し、次の手順でメールを確認しています。

ラベルのついたメールをチェックする
最後に、受信トレイに残ったその他のメールをチェックする

振り分けを行ったことで、通知が埋もれることがなくなり、確認がスムーズになりました。

まとめ

実際にこの振り分けを始めてから気づいたのですが、今までは一通一通メールを開くたびに、無意識に「仕分けの判断」をしていました。例えば、「どのプロジェクトの通知か」「今すぐ確認する必要があるか」「後でまとめて確認すればよいか」といったことです。

ひとつひとつは小さな判断ですが、何十通にもなると、知らず知らずのうちに脳のエネルギーを消耗してしまいます。振り分け設定をした後は、この「仕分けの判断」そのものが不要になりました。

最初からラベルで振り分けられたものから順番に確認していけばよく、効率が上がったと感じています。また、後からメールの確認もしやすくなりました。

こちらの記事もオススメです！

	p5.rbでGenuary 2026に参加してみた Genuary 2026をきっかけに、p5.rbで初めてジェネラティブアート制作に挑戦しました。
	Redmineで働き方を再定義 -OSC2026 Osaka & Tokyo/Spring 出展を通して考えたこと- OSC2026 OsakaとTokyo/Spring の出展を通して、Redmineの運用がうまくいくチームとそうでないチームの違いについて改めて考えてみました。
	Developers Summit 2026 参加レポート Developers Summit 2026に参加しました。刺激的なセッションの数々を振り返ります。
	ファーエンドテクノロジーに入社しましたファーエンドテクノロジーに入社しました。メールからSlackとRedmineの環境に変わって快適になりました。
	オープンデータを表計算アプリで扱うのはちょっと面倒が多いので、Colabで使えるようになったRで処理する Google ColaboratoryでR言語が使えるので、導入準備無しでオープンデータを処理することを考えてみました。

p5.rbでGenuary 2026に参加してみた

2026-03-11T00:00:00Z

Genuary 2026をきっかけに、p5.rbで初めてジェネラティブアート制作に挑戦した記録です
お題「フォントを使わず “Genuary” を描く」に対し、図形だけで文字を構成する表現をコードで実現しました
他の参加者の作品から刺激を受けながら、コードを書いて即ビジュアルに反映される体験の面白さを実感しました

石川です。2026年1月に開催された Genuary をきっかけに、初めて p5.rb に触れたので、そのときのことを書きます。

Genuaryとは

https://genuary.art/

Genuary は、毎年1月に行われるジェネラティブアートのイベントです。https://genuary.art/prompts で毎日提示されるお題を手がかりに各々自分なりに解釈して作品を作ります。例えば2026年1月1日のお題は"One color, one shape."です。31日分のお題が用意されていますが1日だけの参加でも良く、FAQには「プロンプトに完全に従う必要も無い」「使う言語やツールにも決まりがない」等と記載されていて気軽に参加出来ます。

他の人の作品をXのハッシュタグ( #genuary )で見ることができるのですが、同じお題でも人によってまったく違う表現になるのも面白いところです。途中までは他の人の作品を「すごい」「このお題からこういう発想になるのか、なるほど」「綺麗」「これがコードによって生成されているのか...」などと楽しんでいたのですが、だんだんと自分もチャレンジしてみたくなってきて参加しました。

p5.rb

今回チャレンジする上でRubyを使って描きたかったので、p5.rbを使いました。

p5.rb は、JavaScript のクリエイティブコーディングライブラリ p5.js をRuby で扱えるようにした環境です。setup と draw を中心に、図形を描いたり、色や動きをつけたり、乱数で変化を作ったりといった表現を Ruby の文法で試せます。
また、 rbCanvas/p5 や p5.rb Editor などブラウザでコードをすぐ試せる環境もあり、コードを書いてすぐ結果を見ることができて初心者にはとても取っつきやすかったです。

JAN. 5 Write “Genuary”. Avoid using a font.

1月5日のお題"Genuary"をフォントを使わずに描くに挑戦しました。 p5.rb の機能にある丸や三角形、四角形を描くメソッドを使って、図形だけで文字を表現してみました（Eなどは背景色と同じ図形を描画して一部を削っています）。

座標を指定するのが大変だったので、各文字のエリアをboxとして捉えて、そのbox内のどれくらいの位置（0.0〜1.0）に点を置くかを書けばxやyの値を計算できるようにしました。また、これだけだと座標を書いただけになってしまうなと思い、frameCountを元に文字の色を変えたり、背景に薄くアルファが表示されてふわふわと動くようにしました。

実際にコードによって動く画面を https://ishikawa999.github.io/try-creativecoding/genuary-5/ で見ることができます。

コード:

JAN.30 Its not a bug, its a feature.

他に1月30日にもトライしてみました。こちらはイマイチ解釈がしっくりきていないのですが、動くところまでできたので良しとします。

実際にコードによって動く画面を https://ishikawa999.github.io/try-creativecoding/genuary-30/index.html で見ることができます。

コード: https://github.com/ishikawa999/try-creativecoding/blob/main/genuary-30/index.html

Genuary 2026に(少しだけですが)参加した感想

書いたコードがビジュアルに即座に反映されるのが面白かったです。仕様決めやコーディングにもAIを使うのが当たり前になってきた世の中ですが、たまにはこうやって楽しんでコードを書くことも失わないでいたいなと思いました。

X のハッシュタグ #genuary を見ると、同じお題でも解釈の異なる作品が数多く投稿されています。ぜひのぞいてみてください。

こちらの記事もオススメです！

	Redmineで働き方を再定義 -OSC2026 Osaka & Tokyo/Spring 出展を通して考えたこと- OSC2026 OsakaとTokyo/Spring の出展を通して、Redmineの運用がうまくいくチームとそうでないチームの違いについて改めて考えてみました。
	Developers Summit 2026 参加レポート Developers Summit 2026に参加しました。刺激的なセッションの数々を振り返ります。
	ファーエンドテクノロジーに入社しましたファーエンドテクノロジーに入社しました。メールからSlackとRedmineの環境に変わって快適になりました。
	オープンデータを表計算アプリで扱うのはちょっと面倒が多いので、Colabで使えるようになったRで処理する Google ColaboratoryでR言語が使えるので、導入準備無しでオープンデータを処理することを考えてみました。
	本社オフィス増床しました今後の人員増加を見据えて本社オフィスを増床しました。社員皆が快適に働ける環境を整えていきたいです。

ファーエンドテクノロジー株式会社 コーポレートブログ

コードから学ぶ意思決定：ポーカーで考える確率の話

1. コードの中の「勝率」

2. 勝率はどうやって計算されているのか

やっていること

3. カードの枚数ベースで考える

4. でも、全部は計算しない

5. equityと意思決定、そしてAIへ

6. コードから学ぶということ

データベーススペシャリスト試験 合格と学習の振り返り

受験した背景

受験してよかったこと

学習方針

実際の学習内容

午前I対策

午前II対策

午後I・午後II対策

学習を続けるために工夫したこと

受験前に整理していた方針

試験当日を振り返って

午前I

午前II

午後I

午後II

使用した教材

情報処理教科書 データベーススペシャリスト

データベーススペシャリスト「専門知識＋午後問題」の重点対策

書籍以外に参考にしたもの

合格を振り返って

おわりに

参考にした情報の一部

AIを活用してテキストエディタ「Textbringer」のプラグインを作った話

Textbringerとは

AIの活用

作ったプラグインの紹介

textbringer-minibuffer-extension

textbringer-recentf

まとめ

Redmineの通知メールをプロジェクトごとに自動で振り分ける（Gmail）

Redmineのメールヘッダ

Gmailでヘッダを確認する方法

Gmailでヘッダを使ってプロジェクトごとにメールを振り分ける

フィルタの作成手順

まとめ

p5.rbでGenuary 2026に参加してみた

Genuaryとは

p5.rb

JAN. 5 Write “Genuary”. Avoid using a font.

JAN.30 Its not a bug, its a feature.

Genuary 2026に(少しだけですが)参加した感想

ファーエンドテクノロジー株式会社コーポレートブログ

データベーススペシャリスト試験合格と学習の振り返り

情報処理教科書データベーススペシャリスト