はじめにMarkdownでプロジェクトの進捗報告やチームの振り返り資料をまとめていると、定量的な部分にはグラフを入れたくなります。Excelなど外部ツールでグラフを作成して画像を挿入しても良いですが、画像ファイルの管理がちと面倒です。 Mermaid.js はUMLを描けることで有名ですが、実はいくつかのグラフ表示もサポートされています。どうせあまりオシャレじゃないんでしょう？..と、あまり期待していなかったのですが、想定よりオシャレ化ができることが分かったので、この感動を伝えさせてください。 もちろん、見た目や構成ではいくつか制約があります。それさえ許容できれば、テキストでグラフを記述でき、VS Codeなどでのプレビュー以外にも、GitHub・GitLab・Notionなど多くのプラットフォームでプレビューできますし、何よりAIからの支援も受けやすくなりお勧めです。 試してみたナレッジ

はじめに最近、『自省録』を自己啓発として初めて読んでいる。 マルクス・アウレリウスが、誰に読ませるつもりもなく、自分に向かって書き続けた内省のメモ。読んでいると、「日記」って本来こういうものだったんじゃないか、と思うようになった。整っていなくていいし、結論がなくてもいい。ただ、自分の思考と正面から向き合うためのものだ。 そんなタイミングで、2026年の1月ごろから、やたらと「ボイスで日記をつける」系のコンテンツが目に入るようになった。 多くは Google NotebookLM を使った方法で、音声を録音して放り込むと、AIがそれを整理し、要点を抜き出し、ポッドキャスト風にまとめてくれる、というものだ。音声日記を素材にして「今日の出来事」「気づき」「感情の変化」を自動で構造化し、あとから聞き返せるコンテンツにする——そんな使い方を紹介する記事やYouTube動画も多い。 たしかに見栄えはい

最近、事業会社でセキュリティに携わることの難しさについて色々と考えることがあったのでちょっと言語化してみる。いわゆる「セキュリティの知識をキャッチアップするのが大変」という直接的な話ではなく、もう少し構造的な難しさについて。特に何か明快な結論や解決策を提示できるわけではないのだが、自分なりに感じていることを書いてみる。 何が難しいのか 仕組みの理解が難しい セキュリティに取り組むうえで、まず守るべき対象の仕組みをよく理解する必要がある。ここでいう「理解」は、単にそのシステムやサービスを「使える・動かせる」というレベルではない。そこからさらに数歩踏み込んだ、構造や原理の把握が求められる。内部でどのようにデータが流れ、どのコンポーネントがどう連携しているのか。そうした理解がなければ、どこにリスクが潜んでいるのかを見極めることは難しい。 ここでいう仕組みを理解する対象は、例えば自社が提供している

はじめにこんにちは。製造エネルギーサービス事業部の後藤です。 フューチャーでは、社内の有志メンバーが集まり、システム開発におけるベストプラクティスをまとめた「アーキテクチャ設計ガイドライン」の整備・公開しています。 これまでフロントエンドからバックエンド、クラウドインフラ、Git戦略など幅広い分野のガイドラインを公開してきましたが、この度新たに「DynamoDB設計ガイドライン」を公開しました！ 📄 DynamoDB設計ガイドラインはこちら 本記事では、このDynamoDB設計ガイドラインの概要と、特に読んでいただきたい見どころ、ガイドライン作成活動の感想をお届けします。 フューチャーのアーキテクチャ設計ガイドラインとは？フューチャーの設計ガイドラインは「社内の有志が作成する、良いアーキテクチャを実現するための設計ガイドライン」です。 エンタープライズ領域では、高度なセキュリティや保守運

はじめにペンギンになりたいエンジニアの島ノ江です。 普段は CSIG で「FutureVuls」という脆弱性管理サービスの開発を担当しています。 Go1.26リリース連載 の6日目。今回は Go 1.26 で New experimental として追加される runtime/secret を、特にどのような議論がされてきたかについて見ていきます（リリースノート） …と思っていたのですが、既に mattn さんがこのパッケージの概説と実験をされています。本機能の導入によりどのように機密情報の扱いが変わるかについてはこちらの記事をご参照ください。 https://zenn.dev/mattn/articles/64d85241fd3726 そこで、本記事では以下の内容に触れていこうと思います。 前方秘匿性についてGo でのメモリ管理について本機能が提案された背景（issue を遡って）機能概

Go1.26ブログ連載の7本目です。 はじめにテクノロジーイノベーショングループの宮崎です。 Go1.26でcgoが高速化され、約30％速くなったと公表がありました。 これまでなんとなくでcgoを捉えていたので、これを機会にそもそもの仕組みやどのようにオーバーヘッドが短縮されたのか調べてみました。 そもそもcgoとは？そもそもcgoとはGo言語とC言語の間の「橋渡し」を行うパッケージおよび機能のことで、GoのプログラムからC言語で書かれた関数を呼び出したり、逆にC言語からGoの関数を呼び出したりすることが可能になります。 cgoを利用してCのコードを呼び出すには、import "C"という特殊な行を追加し、その直上のコメント（プリアンブル）にCのコードを記述します。このようにすることでC.関数の形式でCのコードを呼び出すことができます。 Goの場合はランタイムが自動的にメモリ管理をしてくれ

はじめに製造エネルギー事業部の辻です。Go1.26ブログ連載 の5本目です。 この記事では、言語仕様のアップデートから new プリミティブの拡張を紹介します。 Go1.25までの new の挙動アップデート内容へ入る前に、Go1.25までの new() の挙動をおさらいしておきます。Go1.25までの new() は、引数に型を指定し、指定された型のゼロ値で初期化し、そのポインタを返す関数でした。 func main() { ptr := new(int) fmt.Println(*ptr) // 0 } あくまでゼロ値を作るためのものだったため、特定の値（例えば 10 や "hoge"）が入ったポインタを作りたい場合は、以下のように2行にわけて書く必要がありました。 v := 10 ptr := &v どうしても1行で書くためのテクニックとしては v := &[]int{10}[0]

はじめにTIG（Technology Innovation Group）の真野です。 Go 1.26ブログ連載 の3日目は、go fix コマンドのアップデートについて解説します。 go fix の出発点リリース内容へ入る前に、go fix そのものについて解説します。 まず、Go 1.26で新しく go fix コマンドが追加されたわけではありません。コマンド自体は2011年4月15日に公開されたIntroducing Gofixというブログで紹介され、その翌月リリースのr57 で追加されました。つまり、誕生から15年近く経過する由緒ある（？）ツールとも言えます。 それにも関わらず、 go fix コマンドはあまり有名で無いと思います。なぜでしょうか。 まず、Go言語が1.0に到達したのは、2012年3月28日で、go fix コマンドが紹介されたのはその1年前です。現在と大きく異なり、

Go 1.26のリリースの足音が聞こえてきたので1.26の新機能のうち、気になる機能を有志で紹介していく連載です。 DateTitleAuthor1/27インデックス+SIMDこの記事渋川1/28goroutine leak profiler武田さん1/29go fix真野さん1/30GCの改善棚井さん2/2new(プリミティブ)辻さん2/3runtime/secret島ノ江さん2/4CGo呼び出し高速化宮崎さん1.26の新機能のダイジェスト久々に結構大きめな変更が多くなっていますね。 new(プリミティブ)1.25で導入されたGCが有効化cgo, memory allocate高速化goroutine leak profilercompilerがスライスをよりスタックに割り当てられるようにSIMDを扱う実験的パッケージ（AMD64のみサポート）runtime/secretという機密情報を

はじめにGo 1.26 リリース連載の 2 本目です。 本記事では Go 1.26 で追加された Goroutine Leak Profiles について紹介します。 アップデートの概要goroutine のリークを検知するためのプロファイルが runtime/pprof に追加されました。 これまでは Uber 社が公開している goleak などを用いてリークを検知するのが一般的なプラクティスでしたが、Go 標準のプロファイル機能を利用して検知ができるようになりました。 リリースノート を参照し、ポイントだけ先にまとめると次の通りです。 runtime/pprof に新しいプロファイル goroutineleak が追加されたnet/http/pprof のエンドポイントとして /debug/pprof/goroutineleak も追加されたGo 1.26 では GOEXPERIME

はじめにTIG（Technology Innovation Group）の真野です。 フューチャーの有志メンバーで取り組んでいる「アーキテクチャ設計ガイドライン」のタスクフォース活動について、2025年の活動実績報告と振り返りの記事です。 アーキテクチャガイドラインとはhttps://future-architect.github.io/arch-guidelines/ フューチャーでは、システム開発の現場で頻出する設計論点とその対応策を体系化したドキュメントをガイドラインとして整備し、GitHub Pagesおよび技術ブログで公開しています。 コンセプトは、単なる手順書や絶対的なルールブックではなくどうすべきかを考えるための議論の土台である点です。プロジェクト固有の事情を削ぎ落とし、汎用的な設計論点と推奨される解決策を提示することで、設計者が最適な判断を下すための補助線となることを意図し

はじめにTIGの真野です。 フューチャーの有志で作成している設計ガイドラインの新作「ソフトスキルガイドライン」の発表です。 https://future-architect.github.io/arch-guidelines/documents/forSoftSkill/softskill_guidelines.html これまではAWSやWeb API、データマネジメントといった技術的な設計指針を中心に公開してきましたが、少し趣向を変えて「非」技術領域にフォーカスしたコンテンツを公開しました1。 本記事では、なぜ今「ソフトスキル」をテーマにしたのか、その背景とガイドラインの概要について紹介します。 なお、本ガイドラインはフューチャーの有志メンバーが「アーキテクトにはこういう能力が必要だよね」という観点を持ち寄って整理したものであり、実験的な位置づけのドキュメントです。 なぜ今「ソフトスキ

中国の浙江大学では超重力装置の「CHIEF1300」が稼働しており、2025年12月22日から「CHIEF1900」の設置も始まっています。CHIEF1300では1トンの物体に1300倍の重力、CHIEF1900では1900倍の重力をかけることが可能で、「超重力場を形成して時空圧縮効果を実現できる」とアピールされています。 世界最大！我国超重力实验装置启动核心设备 - 中国科普网 http://www.kepu.gov.cn/news/2025-09/29/content_409935.html China builds a record-breaking hypergravity machine to compress space and time | South China Morning Post https://www.scmp.com/news/china/science/art

定価 1,562円（本体1,420円＋税10%） 1,718円（本体1,562円＋税10%） 発売日 2025.11.18 判型 B5 頁数 184ページ ISBN 978-4-297-15154-6 概要 第1特集 今さら聞けないID管理 認証基盤を構築する際に知っておくべきこと Webサービスの構築・運用において、ユーザーのID管理や認証・認可のしくみを整備するのは必須であり、OAuth、OIDC、SAMLなどは常に関心の高い技術です。一方で、ID管理機能を漏れなく設計・実装するには、技術以前に「デジタルアイデンティティの管理とは何をすることか」をきちんと知っておかなければいけません。IDaaSを利用するか、自前で構築するかを見極めるために、自社プロダクトの特性や規模、かけられるコストを正しく把握する必要もあります。 本特集では、Webサービスのユーザー認証／ID管理機能を実現する際に

文法はシンプルで学びやすいという特徴を持つGo言語。システム開発の現場でも使われる機会が増えていますが、複雑な要件を実現するにはプログラミング言語が提供するシンプルな構成要素（文法やライブラリ）を、さまざまに組み合わせます。 本書は「よりGoらしく書くには」「実用的なアプリケーションを書くには」といった観点からGoを使うポイントを紹介します。 構造体やインタフェース、またJSON、CSVファイル、Excel、固定長ファイルの扱い方、ログやテスト、環境構築など、また初版の発行後、Goに追加されたジェネリクスについても紹介。現場に即した幅広いトピックについて、「Goらしいプログラムの書き方」を、その背景と共に教えてくれる先輩のような書籍です。 まえがき 1章　「Goらしさ」に触れる 1.1　変数やパッケージ、メソッドなどに名前を付けるには 1.1.1　変数名 1.1.2　パッケージ名 1.1.

たとえば、会議中とかSlackのやりとりで出た、こんなひとこと。 「これをする“目的”と“KPI”は？」 さっきまですぐにアクションに移すべきことを話していたはずが、「目的とKPI」が決まるまで実行することはできなくなり、「なぜやるのか、どう計測するのか」を決めるための会話に時間がとられ、すべてが停滞している。 翌週、やっと目的の話がまとまってきたと思ったら「その目的であれば別の方法が良いのではないか」という話になり、なんのアクションを実行することもできないまま1、2ヶ月が過ぎ、そのうち「検討します」のまま塩漬けになって、その施策の話がされなくなる。 そういうの見たことありませんか？ ぼくは3,600億回あります。 もちろん、KPIや目的を決めるのは良いこと。 KPIや目的を決めること自体は悪くない。 というか、良いことだ。 数字や言語された目的があれば、目的に向かってブレずに動きやすいし

目的と定義本ドキュメントは、従来のプログラミング手法の限界を超えた、AI中心のプログラミング手法として、ラジカルAIプログラミングの概念を定義する。 2002年ごろにブームを起こしたeXtreme Programming (XP) は「昔からあるベストプラクティスを極端(eXtreme)なレベルで適用する」という思想で作られた。コードレビューが有効なら常にペアで開発を行う。テストが有効なら全てのコードでテスト書いてから実装する。ユーザーとの対話が必要ならいつでも会話できる場所にユーザーを座らせるといった具合である。それと同じようなチャレンジをAIを使った開発でもやってみようというのをモチベーションとして自分がAIを使った開発を半年ほど行って得た経験をもとに作成した。RadicalはeXtremeとは違う単語だが似たようなクレイジーさを表現できる単語として選んでいる。4つの価値と12のプラク

エムスリーエンジニアリンググループGMで、データ基盤チームの木田です。 この記事はデータ基盤チーム & Unit9（エビデンス創出プロダクトチーム） ブログリレー3日目の記事です。前回は橋口さんの データ整備の「曖昧さ」に立ち向かう、ドメインエキスパートと協業するための実践的Tipsでした。 本日は、既存のPostgreSQLのさるテーブル (レコード数 100億超) に対して、差分データをSQLで抽出してBigQueryに連携するための索引追加をしたときの経験を元に、PostgreSQLの巨大テーブルに対してFlywayを使用してインデックスを安全に追加する方法についていくつかのテクニックを紹介します。 背景 ナイーブな実装の問題点 CREATE INDEX CONCURRENTLYの使用 Flywayから実行する時の注意点 タイムアウトへの対処 一時領域不足 インデックスサイズを抑える

秋のブログ週間の5本目です。 3年前の秋のブログ週間でデータベースと向き合う決意というエントリーを書きました。3年経ちましたが、多少ベクトルは変わりましたが今も基本的な気持ちは変わっていません。むしろ、「生成AIによって自然言語で気軽に作れるようになった」ことで、SQLの敷居は大きく下がりました。 DFDのガイドライン作りを始めた今年はDFDの本が出ました。5月にブログも書きました。 データフローダイアグラム本の献本をいただきました本書を読んだことで、フューチャー社内のDFDが何を工夫してどのように活用してきたのか、というのを相対的に見れるようになりました。フューチャースタイルも有志で公開しているガイドライン集にいつか入れられたらいいな、ということを思いました。そして、いつか他社のDFD図の発展がどのようになっているのかとかも世の中に出てきて、50年分の図の進化が行われると良いな、という気