はてなブックマーク

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

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

はじめにこんにちは。TIG（Technology Innovation Group）の亀井です。 フューチャー社内の有志メンバーで 非同期設計ガイドライン を作成し、公開しました！ 本記事では、ガイドライン策定の背景や、ガイドラインで取り上げている設計のポイントをピックアップしてご紹介します。 本ガイドライン策定の背景かつて非同期処理といえば、専門的なメッセージングミドルウェアを必要とする、一部のミッションクリティカルなシステムで採用される特別な技術でした。フューチャーでも独自のミドルウェアフレームワークを構築して、大量データをリアルタイムで処理するような仕組みを数々の工夫を凝らして実装してきました。 一方で、昨今ではAWS SQSなどのクラウドネイティブなサービスの登場により、応答時間の長い処理のオフロードなどを目的に非同期処理を取り入れることは珍しくなくなりました。 しかし、非同期特有

同僚の澁川さん、松本さんと一緒に、Software Design 2026年1月号の第1特集「アルゴリズムはどこに効く？」にて、第3章「パフォーマンス問題の診断とアーキテクチャの再考」を寄稿しました。 澁川さんの記事: https://future-architect.github.io/articles/20251218a/今回は記事の宣伝も兼ねて「なぜ今、現場のエンジニアがアルゴリズムやデータ構造を学ぶ必要があるのか？」というテーマで、執筆の裏側にある思いを紹介します。 はじめに正直に言うと、最初に編集部からオファーをいただいた時、引き受けるべきかどうか少し迷いました。 今の私の日常業務において、教科書に出てくるような「アルゴリズム」をバリバリ実装する機会は多くないためです。ソートや探索が必要なら標準ライブラリを使いますし、複雑なデータ処理もSQLやらクラウドのマネージドサービスに任せ

はじめにTIG（Technology Innovation Group）の真野です。 フューチャーの有志で取り組んでいる「アーキテクチャ設計ガイドライン」の活動について、2026年の作成スケジュールを公開します。 アーキテクチャガイドラインとは？アーキテクチャガイドライン」とは、一言で言えば、システム開発の現場で頻出する「よくある設計論点」とその「推奨される解決策」を汎化し、体系的にまとめたドキュメント群です。現在、WebフロントエンドやWeb API、PostgreSQLといった技術領域から、Gitブランチフローやコードレビューといった開発プロセスに至るまで、幅広いテーマをGitHub上で公開しています。 いくつかの強いこだわりがあります。 「ルールブック」ではなく「考えるためのツール」 「これに従えば思考停止でOK」というマニュアルではなく、「何が論点になりやすいか」「なぜその選択肢を

はじめにTechnology Innovation Groupの八木です。 フューチャー社内の有志メンバーでログ設計ガイドラインを作成し公開しました！ ログは、システムの稼働状況を可視化し、トラブルが発生した際に迅速に原因特定するための生命線になります。しかし、その重要性の一方で、プロジェクトごとに設計がバラバラになりがちだったり、とりあえず標準出力しているだけになっていたりと、十分に活用しきれていないケースも多く見受けられます。 本記事では、今回公開したログ設計ガイドラインの背景や、現場で役立つ設計のポイントを抜粋してご紹介します。 ガイドライン作成のモチベーションこれまで、ログ設計は個々のエンジニアの経験則や、プロジェクトごとの慣習に委ねられることが多くありました。しかし、システムが複雑化し、マイクロサービスやクラウドネイティブな構成が当たり前になった現代において、ログの役割は「単なる

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

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

はじめに製造エネルギー事業部の辻です。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]

Green Tea GCの開発タイムライン（出典: Go公式ブログ） はじめにGo 1.26 リリース連載の 4 本目です。 Go 1.26 がリリースされ、ガベージコレクタ（GC）に大きな変更が加わりました。その名も Green Tea GC（緑茶GC）です。 公式ブログによると、この名前は2024年にGoランタイムチームのAustinが日本でカフェ巡りをしながら、大量の抹茶を飲みつつプロトタイプを開発したことに由来しているそうです。 Green Tea got its name in 2024 when Austin worked out a prototype of an earlier version while cafe crawling in Japan and drinking LOTS of matcha! This prototype showed that the co

はじめに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 リリース連載の 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

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という機密情報を

はじめに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。 本記事では、なぜ今「ソフトスキル」をテーマにしたのか、その背景とガイドラインの概要について紹介します。 なお、本ガイドラインはフューチャーの有志メンバーが「アーキテクトにはこういう能力が必要だよね」という観点を持ち寄って整理したものであり、実験的な位置づけのドキュメントです。 なぜ今「ソフトスキ

海外製のチャットサービスとかでIMEを確定しようとしたら勝手に送信されてしまって困った！ という経験をしたかは多いでしょう。日本語入力はIME(Input Method Editor)を通じて行われますが、イベントのハンドリングを間違うとこのような挙動になってしまいます。ウェブフロントエンドのIMEにまつわる2つのトピックを紹介します。 Enterで勝手に送信しちゃうIMEの最初の文字が取れないEnterで勝手に送信されちゃう<input>でテキスト入力を作り、チャットを作りたいとします。わざわざボタンをクリックしないと送信できないのは不便なのでEnterで送信できるようにしようとします。changeイベントやblurではフォーカスを一度外さないと確定にならないため、keydownイベントでEnterを拾って送信したいとします。こんな感じでしょうか？もう令和8年なのでReact Compi

はじめにTechnology Innovation Groupの神崎です。 フューチャー社内の有志のメンバーでAWS設計ガイドラインを作成しました。 この記事では、ガイドライン策定の目的と、その内容を抜粋して紹介します。 ガイドライン策定の目的詳細はガイドライン冒頭に記載していますが、ベストプラクティスを形式知化していくというのが第一の目的です。第二に、設計のベースラインを提供することで、システム固有で考えるべきところ（すなわち設計作業で重要なところ）に時間が使えるようにして、結果として設計品質を底上げできることを目指しています。 そのため、システムを跨いで再利用可能な部分に特に着目しています。 ちなみに、Geminiにガイドラインの目的を問うたところ次の回答でした。上記の思いやエッセンスは取り込めているのではないかと思います。 クラウドファーストが標準となり、システム構築においてAWSを

はじめにはじめまして。2023年10月にキャリア入社した篠原です。 これまではシステム開発がメインでしたが、最近データ分析の業務に関わらせていただく機会がありました。そこで求められる成果物、注力すべきポイント、そして技術選定の観点など、従来のシステム開発とは異なる部分が多く、様々な気づきがありました。 自身の振り返りも兼ねて、その知見を共有したいと思います。 なお、データ分析の目的と流れについてはこちらの過去記事も併せてご覧ください。 データ分析で求められるものと意識すること会社や組織が意思決定を行う上で様々な手法がありますが、データを用いた定量的分析は重要な判断材料となります。 「どこに施策を打つのが効果的だろうか」「施策を打った結果、どのような効果があったのか。その結果を元に今後の動きを考えたい」こうした問いがある際、「正確さ」はもちろんですが、次のアクションへ繋げるために「スピード」

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

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

秋のブログ週間の7本目です。TIG 真野です。 アーキチーム（アーキテクト）やテックリードなどからの設計/開発のレビューで、こんな経験はありませんか？ 「その実装は、この機能ID “BL310” の実装パターンでお願いします」「そのライブラリの採用は見送りでお願いします」「そのミドル（DB）のその機能の利用は原則禁止です。え？ はい、あー、、ガイドラインには…確かに今、書いていないですね。後出しで申し訳ないのですが利用はしない方向でお願いします。開発規約には私がこれから追記しますね。え？ あ、はい。そうですね、今度タイ料理でも食べに行きましょう」難しい要件・厳しい期限・不確実性・そして必ずしも満足とは言い難い体制の中、こっちはベストを尽くしていて、ましてより直感的で意図が明確な設計や実装だと思っていて、ていうか品質やスケジュールで遅延が生じた際に結局、矢面に立つのは自分なのに、否定されてか

こんにちは。製造エネルギー事業部の大前七奈です。 今年に入り、GeminiなどLLMが今までにない進化を遂げています。多くの企業がAI活用を模索する一方で、「AIに何を食べさせればよいか分からない」「データが散在・サイロ化していて使えない」といった課題に直面しています。フューチャー恒例の秋のブログ週間を機に、今回はAI（特にGEMINI-CLI）を利用して、どのようにAIと協働してデータモデリングできるか、直近のデータモデリングのトレンドを調べました。 本記事では、AI活用のROIを最大化するために、なぜ「概念モデル」からデータモデリングを始めるべきか、そして、AI自体をモデリングのパートナーとして活用し、コストパフォーマンス高くアジャイルにデータ基盤を整備する具体的な手法を紹介します。 ※GEMINI-CLI自体を利用するときの注意点やテクニックについてはまた別記事にまとめるため、ここで

※上記サムネイルはChatGPTにて本記事を読み込ませて生成しました。 Future Value Group（FVG）の永井優斗です。 Vue.js連載の8本目です。Vue.js は使いやすく、直感的なテンプレート構文でフロントエンド開発を加速してくれます。しかし、その便利さゆえに「セキュリティをうっかり見落とす」ことがあるのも事実です。 この記事では、Vue.jsで実際にわざと脆弱なアプリを作り、そこからXSS・Cookie・CSRF・レート制限といった脆弱性を一気に体験してみます。ちなみにソースの8割ぐらいは生成AIに生成してもらいました。この記事も生成AIと相談しながら書きました。すごいね。 教材アプリはこちらのGitHub上で公開しています。 ※試すことを優先しているのでUIはシンプルに。そのうちきれいにしたいなあ… はじめに今回の教材アプリは Vue 3 + Vite で構築し、

PostgreSQL 18連載の3本目です。 PostgreSQL 18がリリースされ、仮想生成列についてまとめます。PostgreSQLで従来から利用できた格納生成列や、生成列自体と合わせて紹介します。 生成列生成列は他の列から計算される列のことで、テーブルに対するビューをつくるように、ある列に対してビューのような列を作ることができます。ビューにも、MViewと通常のViewがあるように、生成列も「格納生成列」と「仮想生成列」の2種類があります。格納生成列は、登録/更新時に計算されて物理的にストレージが割り当てられます（MVIEWに似ています）。仮想列は列が読み取られる時に動的に計算されます（Viewに似ています）。 PostgreSQL 12で「格納」生成列が利用可能となり、今回18から「仮想」生成列が利用可能となりました。ここまで説明した内容をざっと、表でまとめました。 特徴格納生成

エンジニアであれITコンサルであれ、抽象的で不確実性の高い、要は「いい感じに進めて！」的なフワッとしたタスクは避けて通れません。 目的: 目指したい姿は決まっている 仮説: 現状の課題はヒアリング結果からざっくり候補はある。正解とは限らない 方針: どう解決するか未議論 例えば、データガバナンスの文脈で説明すると、「全社でデータ利活用促進させたい」というゴールに向けて、現状の「データ権限管理が厳し過ぎるかも」とか、「データ共有文化が無いから」などの仮説があり、「どう持っていくのが良いんだろうね？」とチームで議論が始まったような状況を、ここでは想定します1。 「目的」自体を否定しないのでなければ、よくある進め方は、やるべき「具体的な課題」が何であるか分析・分解・仮説を立てること。そして仮説の真偽を、ヒアリング・実データ・試行などから検証する流れ。課題さえ明確にできれば、対応方針はよりクリアに