コーディングエージェントの現状の整理とエンジニアの仕事の変化について AI によるコーディングの支援はコード補完型からチャット型、そして自律型へと進化しています。この記事では現時点で主流となっているコーディングエージェントの種類とその特徴を整理したうえで、エンジニアの仕事の変化について考察します。 コーディングの仕事における AI 技術の関わりといえば、GitHub Copilot を代表するエディタ補完型が主たるものとして認識されてきました。補完型の AI はユーザーが途中まで書いたコードを補完する形で提案を行うことから、ペアプログラムの相方のような存在として捉えられていました。例えば function add と書き始めると、AI は (a: number, b: number): number { return a + b; } といった形で関数の定義を提案します。ユーザーは Tab
AI 始めました！というと、ミーハーな感じがありますが、15年ほどやってきたソフトウェアエンジニアとしてのキャリアは終わりにして、 2カ月程前から AI エンジニアになりました。ここ5年程は、過去の経験の切り売りしかしていない感じがずっとあったのですが、 全く新しいことを始めて1から勉強し直しているところでとても楽しいです。 Fifteen Years of Dev, Deleted — Hello AI 目次 AI エンジニアって何？ 今までのAI/機械学習と違うところ 自律的なエージェントの構成要素 自律的なエージェントが人間を拡張した先 未来への不安 ブラックボックスを超えて 自然言語が主役になる時代のソフトウェア開発 やりたいこと AI エンジニアって何？ 雑に言えば、この表現が言いえて妙だと思います: 「LLM インテグレーション屋さん」 LLM インテグレーション屋さんになるこ
本規約は、世の中のシステム開発プロジェクトのために無償で提供致します。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 はじめに 本規約はPostgreSQLを使用する開発者向けに、DBのテーブルやカラムの命名・型桁・制約などのスキーマ管理に加え、履歴・排他制御・マルチテナント対応などアプリケーション設計を含む内容についての設計標準を紹介する。 以下の目的・意図で作成するものとする。 DB設計の主な論点／設計項目／設計観点を提供することで、開発者の考慮漏れを防ぐとともに、チームでの設計上の合意形成を手助けするシステム開発における標準ラインとなる設計手法を提供することでナレッジやツールの横展開を容易にする適用範囲 作成
SaaS設計レビュー 観点チェックリスト【2025年版】 SaaS設計における「レビュー観点が足りない」「属人化している」を防ぐための 設計レビュー観点チェックリストを整理しました。 実務でよく聞かれる質問・盲点も交えながら、設計品質を上げる観点を体系的にまとめる試みです。 この記事を英語圏向けに再編したものを MITライセンスのOSSとして公開しています。 👉 SaaS Architecture Review Navigator また、この記事群をAIに活用したい方は、こちらの記事を必ず確認してください。 👉 このドキュメントは要約不可です：構造を壊さずAIに読ませるための手引き：要約・誤読・再生成の抑止 概要 このドキュメントは、SaaSの現場で必要と思われる設計観点を体系化したものです イベント駆動・非同期設計・マルチテナント対応・分散トランザクション・災害対策など、現代的な分散
Deciding what to log is one of the most challenging aspects of application development since it's difficult to foresee which pieces of information will prove critical during troubleshooting. Many developers resort to logging everything, generating a tremendous amount of log data, which can be cumbersome to manage and expensive to store and process. To maximize the effectiveness of your logging eff
最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi
こんにちは、よしこです。 最近、個人的に欲しいツールをVibe Codingで作ることが増えてきたので、私の中で定着してきた進め方をまとめてみようかなと思いました。 ちなみに "Vibe Coding"（雰囲気コーディング）というのは、「人間が音声やテキストで指示を出し、AIが主体となってコードを書くコーディングスタイル」を指すワードです。 私もこのやりかたをするときはほとんどコード書いてません。 要件定義 まずは「何を作るのか」「ターゲットは誰か」「どんな機能が必要か」「画面構成はどうするか」などを決めます。好きなAIとチャットベースで喋りながらまとめていきます。 こっちが全然考えきってなくても、「◯◯なアプリ作りたいんだけど要件定義手伝ってー」から会話を始めれば必要な情報は向こうがヒアリングしてくれます。 ここはChatGPT 4oを使うことが多いです。トーンやノリが個人的な好みと合っ
こんにちは、おきゆきです。Ubieでデータ関連業務を担当しています。 4月9日に開催されたTokyo dbt Meetup #13にて、「dbtとLightdashを社内へ浸透させるまでの取り組み」というテーマで発表させていただきました。当日は多くの方にご参加いただき、たくさんのご質問、誠にありがとうございました！ その中で特にコメントが多かったのは、「データエンジニアが1人の状況で、dbtとLightdashを利用する月間PR作成者が35人以上というのは、具体的にどのようにデータマート開発を進めているのか？」「品質はどのように維持しているのか？」「データモデリングの知見はどのように共有しているのか？」といったご質問でした。 具体的には、以下のスライドで示した数値についてです。 https://speakerdeck.com/okiyuki99/integrate-dbt-and-ligh
こんにちは、Drawer Growthグループ ソフトウェアエンジニアの内田(id:usadamasa, @usadamasa)です。弊社ではApache Icebergの活用*1とともに、一部のアプリケーションにJavaを導入しています。今回は、システムアーキテクチャから一段レイヤを下げてアプリケーションレベルのお話しをしたいと思います。 アプリケーションアーキテクチャの設計と運用課題 アプリケーション開発において、私たちエンジニアは通常、パッケージ構成やレイヤの依存関係、ロギングなどの観点からアーキテクチャを設計します。 しかし、実装との不整合やチーム内での共通認識が不十分なまま進むと、品質課題として潜在化し、やがて本番障害や開発者の疲弊といった形で問題に発展します。また、DevinやClineなどのAIエージェントに適切に実装してもらうにはプロンプトやドキュメントで設計を伝える必要が
はじめに データ活用と生成AI 構造化されたデータと生成AI 事例 Uber LinkedIn Pinterest さいごに はじめに ikki-sanのデータ活用の民主化へのコメントをそうだなと思いながら読んで、最近自分もそんな感じの領域のことをベンダー所属のプロダクトマネージャーとしてやっているので、考えていることをまとめてみる。 この数年間で「データの民主化」はイマイチ進まなかった印象ですが、その原因は「SQLの習得難易度」によるところが大きい。そこに関しては生成AIで相当解決されるはずなので、今後はデータの民主化がスタンダードになると予想しています。— ikki / stable代表 (@ikki_mz) 2025年4月7日 データ活用と生成AI これまで社内に蓄積された構造化されたデータを取得・操作するにはSQLおよびデータベースの理解が必要であり、その理解がない人たちは誰かにデ
決済システムでは、高い耐障害性やスケーラビリティ、柔軟性、またデータの整合性等が特に高度に求められる領域です。本特集では、決済基盤の開発・運営に携わる6社のエンジニアの方々にご協力頂き、決済システムにおける技術選定のポイントや今後の展望を、アーキテクチャ図と共に解説頂きました。 ※ご紹介は企業名のアルファベット順となっております 合同会社DMM.com合同会社DMM.comは、会員数4,507万人（※）を誇る総合サービスサイト「DMM.com」を運営しています。 1998年の創業以来、多岐にわたる事業を展開し、現在は60以上のサービスを運営。動画配信や電子書籍、アニメなどの多様なエンタメサービスに加え、3DプリントやEV充電などのハードウェア分野、AIといった最先端のテクノロジーを取り入れた事業など、様々な事業を手掛けています。 2022年にはサブスクリプション会員システムの「DMMプレミ
【プロンプト付き】AIエージェントと社内DBをつなげて、SQL不要なデータ分析基盤を構築する - BigQuery編 本記事を読むとわかること 1. なぜ今「AIでのデータ分析」が注目されているか 2. SQL不要でデータ分析ができるAIを爆速構築する方法 3. 導入時に気をつけたい“誤回答対策”や“運用”のポイント はじめに「社内にある膨大なデータを活用したいけれど、SQLが書けない…」「エンジニアの協力を仰がないとデータ分析が進まない…」 そんな悩みを持つ方、多いのではないでしょうか。 ここ数年のAI技術の進歩はめざましく、いまやプログラミングスキルがなくてもAIを通して扱うハードルが下がっているツールが増えています。特に、自然言語で指示すると裏側でAIがSQLクエリを生成し、必要なデータをサッと引っ張ってきてくれる――そんな仕組みがいま大注目。いわゆる「Text-to-SQL」と呼ば
Java 24で導入された、JEP 491: Synchronize Virtual Threads without Pinningはwithout Pinningです！ここが重要です。 3行で Java 24からでもVirtualThread上でsynchronizedを使ってもいいわけではなく、これまでどおりできるだけ使わない。 JEP 491はPlatform Threadがsynchronizedを含むVirtual Threadによって占有されることを防ぎ、ほかのVirtual Threadを処理できるようにする。 複数のVirtual Threadで同じオブジェクトをモニタ（≒ロック）しているsynchronized 処理はこれまで通りロックの取り合いで止まる。 背景 Java 24は、JEP 491: Synchronize Virtual Threads without P
導入 こんにちは、株式会社ナレッジセンスの須藤英寿です。 今回は、RAGの要であるEmbeddingの性能を大きく低下させてしまう、文章の特性について解説します。 このブログで紹介している内容は以下の論文を元に作成しておりますので、詳細はそちらをご確認ください。RAGを構成してみたが、どうしても正解の文章を取ってこれない！そんなときはもしかするとこの論文で紹介されているような文章になってしまっているかもしれません。 サマリー Embeddingは、RAGの検索能力の根幹に関わる機能ですが、そのの性能や特性についてはあまり知られてはいません。実は、保管するテキストの文体や分割方法次第で最大90％程度、検索性能が下がってしまいます。 今回紹介する論文では、Embeddingの性能を著しく下げるテキストの特徴を調べ、その性質についてまとめています。特に「文章の位置」、「使用する単語」、「文章量」
現在、IT系の仕事の中でデータアナリストは高い人気を博している。大手を含めて日本企業の大多数は情報活用が出来ていないので、データアナリストやその志望者にはブルーオーシャンが広がっているように見えるかもしれない。しかし、情報の分析・活用の現場で欠けているのはデータ分析のスキルではない。豊穣かつ正確なローデータ（分析用の生データ）の供給源となるべき「まともな基幹システム」である。 「いや、だからこそ分析基盤の整備から始める必要があるんです」とデータアナリストは語るかもしれない。そんな彼らにはあらためて"garbage in, garbage out"の格言を送りたい。garbage（ゴミ）を手間暇かけて整形しても、そこから得られる分析結果は「整形されたゴミ」でしかない。基幹システムがポンコツである限り、分析基盤をいかに充実させても効果は出ない。かつてビッグデータという言葉があったが、企業が抱え
サンプルプロジェクト 構成 イベント駆動と CQRS を意識した、レイヤードアーキテクチャをベースとしたヘキサゴナルアーキテクチャになります。 各層について レイヤードアーキテクチャをベースに、以下の4層に分けています。 プレゼンテーション層: ソフトウェアの入出力を担当 アプリケーション層: ソフトウェアのユースケースを担当 ドメイン層: ドメイン知識を元にしたビジネスのルールや制約、プロセスを担当 インフラストラクチャー層: 技術的関心ごとの全般を担当 ディレクトリ構成 domain/ # ドメイン層 models/ ## ドメインモデルを格納 services/ ## ドメインサービスを格納 application/ # アプリケーション層 use-cases/ ## ユースケースインプットポートを格納 interactors/ ## コマンドにあたるユースケースの実装クラスを格納
実際にコードを用いてスタック領域とヒープ領域の概念を説明します。 person オブジェクトを宣言した時、JavaScript エンジンはオブジェクトの実体をヒープ領域にメモリ割り当てを行い、ヒープ領域にある実体への参照をスタック領域にメモリ割り当てを行います。 const person = { name: 'Taro', age: 24 }; 次のように新しい変数(newPerson)に再代入をすると参照がコピーされ、newPerson も person もヒープ領域に割り当てられた同じ実体に対する参照を持ちます。 const newPerson = person; Object.assign を使って新しいオブジェクトを生成するのは、参照コピーをしないための方法の一つで、よく使われる手法の1つです。 function getName(person) { return person.na
はじめに ZENKIGENデータサイエンスチーム所属の redtea です。原籍はオムロンソーシアルソリューションズ株式会社 技術創造センタですが、社外出向でZENKIGENに所属しており、数理最適化や機械学習を用いたデータの分析業務、それらの結果に基づいた顧客への提案をしております[1]。所属チームでXを運用しており、AIに関する情報を発信していますのでご興味あれば覗いてみてください。 本記事の構成 本記事では想定読者を欲張って、GraphRAG は初めてでサクっと学びたい方から、詳しく学びたい方まで手広くしたいと思っています。そこで、最初に概論としてサクッと学べる短い章を設け、その後に詳しい説明の章が続くようにします。さらに、習うより慣れよということで、最後にハンズオン形式でナレッジグラフの構築から GraphRAG の実装までを行います。すなわち、 サクッと学びたい方は概論だけ読んで
G-gen の奥田です。当記事では、Amazon Web Services（AWS）、Microsoft Azure、Google Cloud（旧称 GCP）が提供するフルマネージドな AI エージェントサービスの比較を行います。 はじめに 当記事について AI エージェントとは ツールとは マルチエージェントシステムとは RAG と併用する効果 3社比較 前提条件 機能比較 料金シュミレーション 想定シナリオ AWS Azure Google Cloud 総評 AWS Azure Google Cloud 詳細の解説 Amazon Bedrock Agents（AWS）の詳細 構成図 プロダクト一覧 できること 対応モデル ツール 料金 Azure AI Agent Services（Azure）の詳細 構成図 プロダクト一覧 できること 対応モデル ツール 料金 Playbooks（G
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.com: Software Architecture in Practice (SEI Series in Software Engineering): Bass, Len, Clements, Paul, Kazman, Rick: Books