Terraform経験者が初めてAWS CDKを利用して感じたギャップ | フューチャー技術ブログ
Terraform連載2026 の4本目です。 TIG（Technology Innovation Group）の八木雅斗です。 2023年の新卒入社以来、IaCツールは一貫してTerraformを利用してきましたが、最近の業務ではAWS CDKを利用しています。 AWS CDKを実際に触ってみて、これまでTerraformの考え方に慣れ親しんでいたこともあり、いくつかギャップを感じる場面がありました。 本記事では、現場のリアルな経験をもとに、システム構築において「Terraformユーザー視点で感じたAWS CDKの思想の違い」や「設計時に考慮が必要だったポイント」について解説していきたいと思います。 利用時のシチュエーションは以下になります。 チーム体制はインフラとアプリでチームが分かれているAWS CDKに直接変更を加えることのあるメンバーは3~4人1環境あたりのCloudForma
DynamoDB設計ガイドライン
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある はじめに AWS が提供するフルマネージドな NoSQLデータベース
DynamoDB設計ガイドラインを公開しました | フューチャー技術ブログ
はじめにこんにちは。製造エネルギーサービス事業部の後藤です。 フューチャーでは、社内の有志メンバーが集まり、システム開発におけるベストプラクティスをまとめた「アーキテクチャ設計ガイドライン」の整備・公開しています。 これまでフロントエンドからバックエンド、クラウドインフラ、Git戦略など幅広い分野のガイドラインを公開してきましたが、この度新たに「DynamoDB設計ガイドライン」を公開しました！ 📄 DynamoDB設計ガイドラインはこちら 本記事では、このDynamoDB設計ガイドラインの概要と、特に読んでいただきたい見どころ、ガイドライン作成活動の感想をお届けします。 フューチャーのアーキテクチャ設計ガイドラインとは？フューチャーの設計ガイドラインは「社内の有志が作成する、良いアーキテクチャを実現するための設計ガイドライン」です。 エンタープライズ領域では、高度なセキュリティや保守運
非同期設計ガイドラインを公開しました | フューチャー技術ブログ
はじめにこんにちは。TIG（Technology Innovation Group）の亀井です。 フューチャー社内の有志メンバーで 非同期設計ガイドライン を作成し、公開しました！ 本記事では、ガイドライン策定の背景や、ガイドラインで取り上げている設計のポイントをピックアップしてご紹介します。 本ガイドライン策定の背景かつて非同期処理といえば、専門的なメッセージングミドルウェアを必要とする、一部のミッションクリティカルなシステムで採用される特別な技術でした。フューチャーでも独自のミドルウェアフレームワークを構築して、大量データをリアルタイムで処理するような仕組みを数々の工夫を凝らして実装してきました。 一方で、昨今ではAWS SQSなどのクラウドネイティブなサービスの登場により、応答時間の長い処理のオフロードなどを目的に非同期処理を取り入れることは珍しくなくなりました。 しかし、非同期特有
ログ設計ガイドライン
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある 対象スコープアプリケーションが出力するログ（アプリログ）が対象AWS
ログ設計ガイドラインを公開しました | フューチャー技術ブログ
はじめにTechnology Innovation Groupの八木です。 フューチャー社内の有志メンバーでログ設計ガイドラインを作成し公開しました！ ログは、システムの稼働状況を可視化し、トラブルが発生した際に迅速に原因特定するための生命線になります。しかし、その重要性の一方で、プロジェクトごとに設計がバラバラになりがちだったり、とりあえず標準出力しているだけになっていたりと、十分に活用しきれていないケースも多く見受けられます。 本記事では、今回公開したログ設計ガイドラインの背景や、現場で役立つ設計のポイントを抜粋してご紹介します。 ガイドライン作成のモチベーションこれまで、ログ設計は個々のエンジニアの経験則や、プロジェクトごとの慣習に委ねられることが多くありました。しかし、システムが複雑化し、マイクロサービスやクラウドネイティブな構成が当たり前になった現代において、ログの役割は「単なる
Go1.26リリース連載：newプリミティブの拡張 | フューチャー技術ブログ
はじめに製造エネルギー事業部の辻です。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]
Go 1.26の新GC「Green Tea（緑茶）」解説 | フューチャー技術ブログ
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
Go 1.26で go fix が面白くなった | フューチャー技術ブログ
はじめに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年前です。現在と大きく異なり、
アーキテクチャガイドライン振り返り（2025年）～15本を作成してみてどうだったか～ | フューチャー技術ブログ
はじめにTIG（Technology Innovation Group）の真野です。 フューチャーの有志メンバーで取り組んでいる「アーキテクチャ設計ガイドライン」のタスクフォース活動について、2025年の活動実績報告と振り返りの記事です。 アーキテクチャガイドラインとはhttps://future-architect.github.io/arch-guidelines/ フューチャーでは、システム開発の現場で頻出する設計論点とその対応策を体系化したドキュメントをガイドラインとして整備し、GitHub Pagesおよび技術ブログで公開しています。 コンセプトは、単なる手順書や絶対的なルールブックではなくどうすべきかを考えるための議論の土台である点です。プロジェクト固有の事情を削ぎ落とし、汎用的な設計論点と推奨される解決策を提示することで、設計者が最適な判断を下すための補助線となることを意図し
AWS設計ガイドライン
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある はじめに 技術選定におけるクラウドファーストは標準となって久しく、新
AWS設計ガイドラインを公開しました | フューチャー技術ブログ
はじめにTechnology Innovation Groupの神崎です。 フューチャー社内の有志のメンバーでAWS設計ガイドラインを作成しました。 この記事では、ガイドライン策定の目的と、その内容を抜粋して紹介します。 ガイドライン策定の目的詳細はガイドライン冒頭に記載していますが、ベストプラクティスを形式知化していくというのが第一の目的です。第二に、設計のベースラインを提供することで、システム固有で考えるべきところ（すなわち設計作業で重要なところ）に時間が使えるようにして、結果として設計品質を底上げできることを目指しています。 そのため、システムを跨いで再利用可能な部分に特に着目しています。 ちなみに、Geminiにガイドラインの目的を問うたところ次の回答でした。上記の思いやエッセンスは取り込めているのではないかと思います。 クラウドファーストが標準となり、システム構築においてAWSを
Webフロントエンド設計ガイドライン
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある はじめに 昨今のWebフロントエンド領域は、単なるHTML、CSS、
PostgreSQLの全文検索機能を試してみる | フューチャー技術ブログ
夏の自由研究2025ブログ連載の4日目です。 技術コンサルをしているお客さんとPrismaのドキュメントの読書会をしていて、全文検索機能がPrismaにも、PostgreSQLにも標準で用意されているということを知りました。PostgreSQLで全文検索はというと、PGroongaとか、pg_bigmを使うとかがトップ出てくるし、そもそも検索をしたくなったらElasticSearch使う、みたいに思っていました。 標準で全文検索もできるなら運用コストもだいぶ下げられそうです。かつて、Python製ドキュメントツールの、ブラウザで動く全文検索エンジンの日本語対応をやってみたり、FM-indexという高速文字列解析の世界という書籍で紹介されていたアルゴリズムを使ったブラウザで動く検索エンジンを作ったり、転置インデックスをS3に置く検索エンジンを作ってみたり貧乏低コスト検索エンジンの第一人者(自
バッチ設計ガイドライン
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある はじめに バッチ処理とは、大量のデータを一括で処理するための手法であ
アーキテクチャ設計ガイドライン
フューチャー株式会社の有志が作成する良いアーキテクチャを実現するための設計ガイドライン
Terraform設計ガイドライン
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある はじめに Terraformはインフラを宣言的にコード管理するツール
Terraform設計ガイドラインを公開しました | フューチャー技術ブログ
こんにちは。TIGの伊藤です。 Terraform連載2025の6日目の記事です。 2025年始から、社員の有志でTerraform設計ガイドラインを編集し、先日公開したので公開までの経緯などについて触れていきます。 公開までの経緯Future Enterprise Arch Guidelinesとして、これまでにもWebAPI設計ガイドライン、Slack利用ガイドラインなどを公開してきましたが、これらは社内に知見が溜まってきていることをきっかけに、ガイドラインとして整理して公開しています。 Terraformについても、社内の複数プロジェクトで利用されており、それぞれで工夫したこと、ケアしたポイントなどが知見として出てきていることから、社員がリファレンスとすることも含めて編集、公開することになりました。 チームにおけるガイドラインを設けることの難しさ各プロジェクト、チームでは一定のコーデ
Gemini、社内利用スタート！ | フューチャー技術ブログ
米国時間の2025年1月15日に「Google AI の優れた機能を Google Workspace の Business プランと Enterprise プランに組み込むことを決定しました」でもアナウンスされた Gemini が、ついに当社内でも利用が始まりました。Chatbot Arena で常連の Gemini モデルが業務で使えるようになり、とても熱い展開なのでブログ化しました。 はじめにこんにちは。tanai（棚井龍之介） です。 先日、ある企業さんのオフィスへ訪問した際に、「ウチでは、〇〇（←誰もが知っている生成AIサービス）は、全員にアカウントが支給されているよ」という話を伺い、とても羨ましいなと思っていました。私の場合、業務外で ChatGPT Plus、Felo Pro、Gemini Advanced、Mapify Pro を中心に課金して、他サービスもお試し利用しなが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Future Enterprise Arch Guidelines