はてなブックマーク

はじめにこんにちは。TIG-DXの藤井です。 当社の有志メンバーの協力により、アーキテクチャ設計ガイドラインというものを作成・公開しています。 各分野におけるアーキテクチャ設計の指針となるべく作成されているガイドライン集ですが、この度、新たにメール設計ガイドラインを作成しました。 本記事では、このメール設計ガイドラインについて、内容にも触れつつご紹介をしていきます。 メール設計ガイドライン概要皆さん、普段からメールは利用されているかと思います。その手軽さ・利用者の多さから、純粋なコミュニケーションツールとしてはもちろん、webシステムにおけるユーザ認証や、販促・各種取引など、多岐にわたって活用されています。 一方、実際にメールという通信手段がどのように実現されているのか・どういった技術が利用されているのか、等を意識することはあまり無いのではないでしょうか。 当然のことではありますが、メール

はじめにJava 24 & 25のリリース連載第 2 弾の記事です。 第 1 弾の記事 に引き続き本記事では Java 24 のアップデートを取り上げます。 JEPsJava 24 で対応された主要な 21 の JEP（Java Enhancement Proposals）は次の通りです。 Oracle の プレスリリース をベースにカテゴライズしています。 カテゴリJEPタイトル言語機能JEP 488Primitive Types in Patterns, instanceof, and switch (Second Preview)言語機能JEP 492Flexible Constructor Bodies (Third Preview)言語機能JEP 494Module Import Declarations (Second Preview)言語機能JEP 495Simple Sou

はじめにこんにちは。TIG（Technology Innovation Group）の本田です。 フューチャー社内の有志メンバーでバッチ設計ガイドラインを作成し、公開しました。 本記事ではガイドラインの作成の経緯や想いなどを簡単に紹介します。 本ガイドラインの対象読者本ガイドラインは、以下のような方を主な読者として想定しています。 バッチ開発を行う初学者バッチ処理を含むシステム設計を行う人自身のメイン領域はバッチ処理ではないがバッチ処理設計の勘所を知っておきたい人特に初学者の方はジョブ設計の章だけでも読んでいただくことをオススメします。バッチ処理のプログラムを実装する上で留意するべき冪等性や性能といったポイントが紹介されています。 本ガイドラインの作成経緯フューチャーでは様々な規模のシステムを構築しており、その中には多種多様なバッチ処理も含まれます。 cronのようなシンプルなスケジューラ

はじめにこんにちは。TIGの長谷川です。 フューチャー社内の有志メンバーでWebフロントエンド設計ガイドラインを作成し公開しました！ 本ガイドラインではガイドライン策定の背景やガイドラインの特徴に加えて、内容の一部をピックアップしてご紹介します。 本ガイドラインの背景昨今のWebフロントエンド領域は、単なるHTML、CSS、JavaScriptでのページ制作から大きく変化しました。React、Vue.jsなどのモダンなフレームワークを活用した大規模かつ動的なWebアプリケーションの構築が主流となっています。 これにより開発の効率化とユーザー体験（UX）が向上しています。しかし一方で、設計の考慮点も多様化し、セキュリティやアクセシビリティなど、より多面的な品質も求められるようになりました。 本ガイドラインでは、Webフロントエンド設計における考慮点・設計パターン・推奨手法を提示し、開発チーム

こんにちは、starswirl_kです。 今回は、チーム開発でMermaid図を頻繁に利用している中で、「もっとこうなったら良いのに！」という現場の声を形にした自作ツールをご紹介します。 特に、フローチャートやクラス図の矢印の長さ（ノード間の間隔）や垂直方向の間隔といった細かい調整に悩んでいる方には、きっと役立つはずです。 ツールはこちら：GitHub Pages/MermaidViewer.html なぜこのツールを作ったのか？Mermaidは手軽に図を作成できる非常に便利なツールですが、デフォルトの設定では図の要素間の間隔が固定されているため、複雑な図になると矢印が短く見づらかったり、全体のレイアウトが窮屈に感じられることがありました。 特に、以下のような課題がありました。 矢印が短い: 図の要素が増えると、関係を示す矢印が短くなり、どこからどこへ繋がっているのか視認性が悪くなる。レイ

夏の自由研究2025ブログ連載の7日目です。 フューチャー技術ブログの「関連記事」の表示ロジックの変遷と今後についてまとめます。 背景フューチャー技術ブログは開設以来、Hexoという静的サイトジェネレータを利用しています。そのため、サイトの構造や記事のレイアウトは完全にフルスクラッチで自由度が効く反面、全てを自分たちで（できれば、手間と時間をかけずに）行う必要があります。 創設が2016年、9年半が経過し現在1300ほどの記事が投稿されています。中にはバズって数万PVに届く記事もあります。せっかく、ある記事を見てもらったのであれば、他の記事をついでに見てもらうことで回遊率を上げたいという気持ちがあります。また、社内のナレッジ管理の側面では「know who」が重要なので、似たような記事を書いた人を辿れるようにしておくことは、ポリシー的に大事にしたいポイントです。 1300記事もあるとユーザ

夏の自由研究2025ブログ連載の4日目です。 技術コンサルをしているお客さんとPrismaのドキュメントの読書会をしていて、全文検索機能がPrismaにも、PostgreSQLにも標準で用意されているということを知りました。PostgreSQLで全文検索はというと、PGroongaとか、pg_bigmを使うとかがトップ出てくるし、そもそも検索をしたくなったらElasticSearch使う、みたいに思っていました。 標準で全文検索もできるなら運用コストもだいぶ下げられそうです。かつて、Python製ドキュメントツールの、ブラウザで動く全文検索エンジンの日本語対応をやってみたり、FM-indexという高速文字列解析の世界という書籍で紹介されていたアルゴリズムを使ったブラウザで動く検索エンジンを作ったり、転置インデックスをS3に置く検索エンジンを作ってみたり貧乏低コスト検索エンジンの第一人者(自

夏の自由研究2025ブログ連載の2日目です。 はじめに人生は選択の連続ですが、何を選択するかどうやって決めていますか？ おそらくはメリット/デメリットを鑑みて方向性を決める方が大半だと思います。時には、どう転んでも結論は一緒の場合やメリデメで考えない場面もあるとは思いますが、巨額マネーが動くケースではそうもいきませんよね。 今回は、サイバーセキュリティ界隈の文脈で「リスクの可視化～意思決定」がどのように行われるのかをお話します。これはプライベートでも仕事でも、おおよそ生きていく上で役立つ考え方にも応用できると思います。 リスクアセスメントとはビジネスはいかに精度よく予測して経営計画を立て、調整力と実行力で推進し、残りは運、そんな感じのポートフォリオかと思います。もちろん経営者の方の中には長年の勘やデータからは読み取れないが物理的な何某か（ex. 生きている消費者から直接感じ取る波動や世間の

ブログ運営の立場として、この生成AIブームな時代に「◯◯について技術ブログを書いてください！」と依頼し続けて良いのか？そんな疑問が湧きました。 情報収集はAIに聞けばいいし、書くこと自体もAIが手伝ってくれます。それでもなお、個人として技術ブログを書き、そして人に勧めるの理由を言語化しておきたい。 今回は、なぜ今あえて技術ブログを書いた方が良いのか、会社Slackのブログ寄稿者チャンネルで太田さん、澁川さん、枇榔さん、山本さん、橋本さん、村田さん、村瀬さん、柏木さんと相談した結果をまとめました。 自分のため結局のところ、一番大きいのは自分のため。 スキルアップ書く過程で、曖昧だった知識が整理される。疑問を調べて解消することで、より深く理解できるアウトプットすることで、社内外からフィードバックをもらえて、さらに詳しくなれる地味に文章力も上がる。どんな仕事でも役立つセルフブランディング自分のス

Slack、便利ですよね。フューチャーでも2020年の本格導入以降、多くのプロジェクトで使われており、もはや仕事に欠かせない空気のような存在です。 先日、Slack利用ガイドラインを考えるチャンネルで、Slackの「困った使い方」について話しました。オープンな文化を守るために大事だと思ったので、ブログにまとめました。 探せばありそうな残念な光景発端は、mizchiさんのとあるXのポストでした。これをきっかけに、こんな感じの会話をしました。 Aさん: @channel を連投する人がいて、結局ミュートされて機能不全になるの、不謹慎ながらちょっと笑ってしまいました。幸い、自分の周りにはそこまでの人はいなかったし、DM（ダイレクトメッセージ）を多用して情報の非対称性を作るなどで、社内政治する人も見たことないです。 Bさん: 昔、大きめのプロジェクトで @channel を連投に近いことをする人な

はじめにコアテクの山口です。 フューチャー社内の有志メンバーでI/F設計ガイドラインを作成し、公開しました。 I/F設計ガイドライン | Future Enterprise Arch Guidelinesシステム開発、特にエンタープライズ領域においてシステム間のデータ連携は避けて通れません。 本ガイドラインは、クラウドネイティブな環境におけるモダンなシステム間連携の設計指針を提供することを目指しています。 アピールポイント連携方式の選定といった上流のアーキテクチャ設計から、ファイル形式や冪等性といった下流の詳細設計、そして結合テスト計画の指針まで網羅されたガイドラインになっています。 ピックアップコンテンツ今回のガイドラインもボリュームがあるため、一部コンテンツを抜粋してご紹介します。 統合パターンシステム間連携の方式として代表的な4つの統合パターン（DB共有、RPC、メッセージング、ファ

Go 1.25 リリース連載 の5本目です。 はじめにこんにちは、CSIG FutureVuls の市川です。 testing/synctest パッケージについて紹介します。Go の testing/synctest は、Go1.24 で experimental として追加され、 Go1.25 で正式なパッケージとなりました。 過去のリリース連載で棚井さんが詳しく解説した記事を書いてくださっています。synctest の基本的な説明についてはぜひご参照ください。 本記事は以下の流れで説明し、具体例を用いて durably blocked と synctest.Wait() についての理解を深めます。 synctest の概要とメリットexperimental からの変更点durably blocked の定義synctest.Wait() の挙動synctest の概要とメリットsyn

はじめにこんにちは。ペンギンになりたいエンジニアの島ノ江です。 現在は FutureVuls という脆弱性管理サービスの開発・営業などを担当しています。 Go 1.25リリース連載の4本目、マイナーアップデートの net/http での CSRF 対策の強化について触れます。 この記事では、以下の内容について触れていきます。CSRFについて既知の場合はリリースの実装内容の項目を参照してください。 今回のリリースの概要CSRFの概要issue提案の背景リリースの実装内容関連する issue はこちらです（issue） 今回のリリースの概要新たに net/http に CrossOriginProtection が実装され、安全でない Cross-Origin ブラウザリクエストを拒否することで、CSRF から保護するようになりました。これまでの Go では、標準ライブラリの net/http

はじめに製造エネルギー事業部の辻です。Go1.25 リリース連載 の3本目です。 マイナーアップデートから sync パッケージを取り上げて紹介します。 アップデートサマリThe new method on WaitGroup, WaitGroup.Go, makes the common pattern of creating and counting goroutines more convenient. https://go.dev/doc/go1.25#syncpkgsync sync パッケージに新しく WaitGroup.Go() というメソッドが追加されました。ゴルーチンの生成と完了を集計する一般的なパターンを便利に記述できるようになりました。 このメソッドを利用すると、たとえば以下のような並行処理のコードをより簡潔に記述できるようになります。 Go1.24以前var wg

はじめにGo 1.25 リリース連載 の 2 本目です。 本記事では log/slog パッケージ のアップデートについて紹介します。 Go の log/slog パッケージは、Go 1.21 で導入された構造化ロギングをサポートする標準ライブラリです。 本記事では slog についての基本的は割愛しますが、slog の概要やこれまでのアップデート経緯をつかみたい方は、過去のリリース連載記事を参照してください。 Go 1.21 連載始まります＆slog をどう使うべきかGo 1.22 リリース連載 vet, log/slog, testing/slogtestアップデートの概要リリースノート を参照してみましょう。 GroupAttrs creates a group Attr from a slice of Attr values. Record now has a Source met

Go 1.25 のリリースが近づいてきました。今回は比較的シンプルなアップデートかなと思います。 DateTitleAuthor7/30この記事渋川7/31log/slog武田さん8/1sync辻さん8/4net/http島ノ江さん8/5testing/synctest市川裕也さん8/6json/v2後藤さん8/7go vet真野さんGo 1.25 更新のオーバービュー執筆時点では現在 RC2 が最新です。この時点のリリースノートを参考にしています。たまに直前で一部の機能のリリースがキャンセルになったりしますが、今回はどうでしょうか？ go build -asan オプションでプログラム終了時のリークのチェックが行われるようになった。C で割り当てられたメモリが C からも Go からも参照されなくなった状態で残っていたらエラーにインストーラでバイナリとして提供されるツールが減って必要に応

子どもを寝かしつける際にふと、「伸びる人の条件ってなんだろう？」と考えだしたら止まらなかったので、会社Slackのスーパー雑談チャンネルで投げかけてみたところ、有益かつ面白いやり取りができたので議論をまとめました。 新卒採用の面接でよく聞かれる話題でもありますね。 最初に出た「伸びる人の条件」たちまず、みんなから出てきたのはこんな感じです。 素直である（言われたフィードバックをプライド邪魔せず受け取れる、理由もなく自分のやり方に固執しない）ロジカルシンキング / クリティカルシンキングができる手が早い、まずやってみる精神壁を作らず、越境できる与えられた役割を全うし、さらに広げようとする業務を通じて勝手に学べる（関連領域への興味関心）ゴールイメージが持てる、またはそれが分からなければ端的に聞けるどれも「たしかに」という感じです。特に「越境」や「戦場で強くなるタイプ」は、実務での成長を考えると

こんにちは、FVGの村田です。AI Tips連載の7日目の記事です。 はじめに私は今フューチャー社内のバックオフィス業務をターゲットに生成AI活用を更に促進させるミッションを担い、日々業務に勤しんでいます。 バックオフィスの方へのヒアリングを通じて、生成AIの活用（本記事においてはGeminiの活用を想定）を通じて効率化・省力化を狙いたい業務シーンやニーズがいくつか浮かび上がってきました。 私自身もまだまだ生成AIの使い方を勉強している身ですが、各シーンにおいて現時点で考えられる好ましい使い方を模索したい、というのが本記事のモチベーションです。 ※本記事では Gemini 2.5 Pro の利用を前提とします。 効率化・省力化を狙いたい業務シーン・ニーズ3選【シーン① マーケ】 ブログ記事の定期アナウンス用メール文面の作成作業を省力化したい 【シーン② 総務など】 業務にて利用するGASを

AI Tips連載の5本目の記事となります。 はじめにこんにちは。Strategic AI Group (SAIG) の藤井です。 GENIAC第2期事業にて採択された「日本語とソフトウェア開発に特化した基盤モデルの構築」プロジェクトに関する取り組み紹介、全2編の後編です。 前編では、開発したモデルの概要や開発の流れ、プロジェクト進行における反省点をご紹介しました。後編では、モデルの技術的特徴に関するより込み入った内容や、取り組みの中では明らかに出来なかった今後の検討課題・オープンクエスチョンを共有します。 改めて、本プロジェクトで開発したモデル Llama-3.1-Future-Code-Ja-8B はHugging Faceにて公開しております。 商用利用も可能な許容的ライセンスで公開しておりますので、ぜひ幅広く試して (遊んで) いただけると嬉しいです。 モデル学習における気づき・学

AI Tips連載の4本目の記事となります。 はじめにこんにちは。Strategic AI Group (SAIG) の藤井です。 GENIAC第2期事業にて採択された「日本語とソフトウェア開発に特化した基盤モデルの構築」プロジェクトについて、開発の過程で得られた知見や学び、今後の課題を共有します。 みなさまご存じの通り、生成AI技術を取り巻く状況は日進月歩であり、殊にコーディングをはじめとしたソフトウェア開発ドメインでは、(人間を含む) 環境のフィードバックを受けながら自律的に問題解決を行うエージェントなど日夜新たなツールが登場しています。その意味で「ソフトウェア開発×基盤モデル」は血の海であり、どのような方針・立ち位置を取るかという部分に非常に頭を悩ませました。 本稿は前後編の2本立てで、前編は開発したモデルの概要や開発の流れ、プロジェクト進行における反省点について、後編ではモデルの技

本記事は、AI Tips連載の1本目の記事となります。 はじめにこんにちは。HealthCare Innovation Group(HIG)の山本竜玄です。 業務やプライベートを通して、GeminiやGitHub Copilot、Cursor、Claudeなどを使用していますが、これらのAIエージェントツールをうまく使うにはプロンプトエンジニアリングの知識が必要だと実感しています。 例えば、Few-Shot Prompting（数個の例を与えてつつ、同様のタスクを依頼する）であったり、Tree of Thoughts（複数の選択肢や段階を並行して評価・検討させる）などを意識すると、AIからの回答の質が大きく向上します。 これらの手法を勉強する中で、ふと思ったことがあります。プロンプトエンジニアリングで使われる思考法は、LLMへの指示だけでなく、人にタスクを依頼する際や、自分のスキル改善につ

本記事は、CI/CD連載の6本目の記事となります。 はじめにこんにちは。HealthCare Innovation Group(HIG)の山本竜玄です。 本記事では、Gemma3とUnslothを組み合わせて、完全オンプレミス環境でのAIコードレビューができる環境を構築してみました。 フューチャーでは社内開発基盤運用チームが構築・運用するオンプレミス版GitLabを利用していますが、近年注目されるAIエージェントを導入する際に課題がありました。外部APIを利用する場合、セキュリティ審査プロセス、従量課金による予算管理の複雑さ、機密データの外部送信への懸念などが発生します。 そこで、LLMモデルを自前の環境に組み込み、プロジェクト固有のデータで追加学習を行うアプローチを試しました。Gemma3とUnslothの組み合わせにより、RTX 3060 12GBという家庭用レベルなGPU環境でもファ