Over the past year, we've worked with dozens of teams building large language model (LLM) agents across industries. Consistently, the most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns. In this post, we share what we’ve learned from working with our customers and building agents ourselves, and give

巷では「AIエージェント」のワードをよく見かける一方、何をAIエージェントと定義するのか自分もフワっとしていたので、2024年12月20日に公開されたAnthropicの「Building effective agents」の記事を読んでみました。 「AIエージェントの定義ははっきりと定まっていません」みたいな文言は方々で見ますが、各社がどういう見解でそのワードを使っているのか、なんとなく理解することはできます。 ちなみに、以下の「うたたね / Masaki Otsuki」さんの記事では各社がどのような位置付けとしているのかがまとまっており、私も勉強させていただきました。ありがとうございます。 ※本記事ではAnthropicの記事に焦点を絞り、記事の内容を元に記述しています。 エージェントとワークフローの違い ワークフロー: LLMとツールが事前定義されたコードのパスを通じて調整されるシス

TL;DR perplexity のスペースは情報源をURLとファイルで登録できる →質問するとそこを優先的に検索 →githubや公式サイト、ドキュメントを登録する →ソフトウェアの調べものがはかどる! 注意点: 日本語で質問すると日本語で検索しようとして失敗する。プロンプトで「(質問本文) 英語で検索して日本語でまとめて」って書くとよい perplexityのスペース perplexity、検索まとめと、翻訳があやしいニュースサイトとしてそこそこ便利に使っています。 ちょっと前から「スペース」という機能ができていたのですが、使ってみたところ予想以上にいい感じでした。 スペースはここ スペース機能は複数人で共有されるスペースを作って、特定のトピックについてperplexityとのchat履歴をまとめる機能です。ここで、ソースとして情報源のファイルやリンクを登録することができます。 ソース

はじめまして、ますみです！ 株式会社Galirage（ガリレージ）という「生成AIに特化して、システム開発・アドバイザリー支援・研修支援をしているIT企業」で、代表をしております^^ この記事では、入門者向けの「RAG」の開発手法を解説します！ もしもPythonを使ったことがない方は、下記のZenn本を参考にしてください。 また、RAGについての基礎知識を学びたい方は、下記のZenn本を参考にしてください。 さらに、RaggleというRAGの精度を競うコンペを開催しているため、ご興味のある方は、こちらのコンペを通して、RAGのスキルアップにご活用ください！ なんと1位の人には、賞金30万円も付与されます🏆 それでは、早速解説をしていきます！ この記事の内容を習得すれば、Raggleに応募できる状態になるため、ぜひ皆さんもRaggleのコンペに挑戦していただけたら幸いです^^ 全体の流れ

2024年に読んで印象に残った本の技術書編です。去年はそんなに多くの冊数は読めていません。というか、技術書を執筆して出版したので、技術書そのものにお腹いっぱいだったのは大きいと思います。 本を書いたという話は下記です。 blog-dry.com 非技術書編を先に書いているので、よかったらこちらもどうぞ。 blog-dry.com 免責事項ですが、記憶を元に書いている箇所が含まれることがあります。また、書籍のリンクにはアフィリエイトコードが付与されているので、苦手な方はURLから外してご購入ください。 目次 ルールズ・オブ・プログラミング Tidy First? Domain Modeling Made Functional 大規模データセットのためのアルゴリズムとデータ構造 コード×AIーソフトウェア開発者のための生成AI実践入門 モデル検査器をつくる〜Goで実装して学ぶ形式手法〜 まとめ

1章　事業活動を分析する この章は事業活動を理解するためのドメイン駆動設計の考え方とやり方が解説されています。 感想 ドメイン駆動設計は事業活動と構造を理解するところから始まります。 理想的には設計者や開発者が業務全体を完全に理解したうえで設計や開発を進めることが望ましいです。 しかし、現実としては設計者や開発者がすべての業務を完全に理解することは極めて難しいです。 そこで重要となるのがコミュニケーションとなります。 業務エキスパートと密にコミュニケーションをとり、本来の意図を漏れなく汲み取ることがなにより重要になると思います。（どのようにくみ取るかは次章で解説されています。） この辺りはSIerとして参画する場合に特に必要とされると思います。 いかにステークホルダーを巻き込みながら業務エキスパートとの信頼関係を築けるかが、プロジェクトの成功を左右すると言っても過言ではないと思います。 2

私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ。 本当にそのとおりだった。読んでる途中で既に自分の設計に対する考えが良い方向に変わってると感じた。とても良かった。おすすめです。 『Tidy First?』 をいただいて読んだ。昨日（2024年12月25日）発売。英語版が2023年11月28日発売だから、たった1年で日本語版が出たということだな。うれしい！はやい！ありがたい！ ソフトウェア設計に焦点を当てたシリーズの最初の1冊ということで、サブタイトルに「個人で実践する経験主義的ソフトウェア設計」とあるように、1人でできる種類のソフトウェア設計について書かれている。続刊ではチームについての話になる予定のようで、それも今から楽しみ。 2周読んだ なんとなく2周読もうと思ってそうした。 1周目は細かい部分は気にせずにざーっと1,2時間くらいで読んだ。全体的にどうい

TL;DR 令和に踏み台サーバーを作成する Amazon Linux 2023AMIとSSM Agentを利用したEC2 証跡を取得する About EC2とSSMのセッションロギングを使用して証跡を取得することが目的。 ECS/Fargateでも同様のことが可能ですが、SSM AgentがプリインストールされているAMIのEC2を使い捨てる方が運用コスト的や構築コスト的に楽なためEC2を選択。 How To アーキテクチャ Instance Profileの作成 assumerole.json $ cat <<EOL > assumerole.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action

こんにちは！逆瀬川 ( https://x.com/gyakuse ) です！ 生成AI Advent Calendar 2024の記事を書くの忘れていたので、現時点での生成等AIの進歩をまとめてみました！今日はAIがいまなにできんの？ってこと聞かれたときにこれできるよ！って教えるためのメモとして活用してください！また、生成AIプロダクト Advent Calendar 2024というのもソロでやっています。このカレンダーではLLMの基礎理論からModelのFine-Tuning、プロダクト開発等をまとめています。ぜひこちらも見てください！ 未来を感じる技術の進歩 動画生成では、Veo2 や Sora が登場しました。 インタラクティブな動画生成では、Genie2 (WASDと方向キーで操作可能な世界モデル)が非常に革新的な進歩を遂げています (振り返っても一貫性を保つ長期性が本当にすごい

Thank you for visiting nature.com. You are using a browser version with limited support for CSS. To obtain the best experience, we recommend you use a more up to date browser (or turn off compatibility mode in Internet Explorer). In the meantime, to ensure continued support, we are displaying the site without styles and JavaScript.

毎年必ずどこかでウォーターフォールとアジャイルを対立させ「ウォーターフォールwwwww」と味付けしたツイートに待ってましたと総ツッコミが入るムーブがあるように思います。 今シーズンは下記のツイートがK点超えの大ジャンプを記録しました。 今どきウオーターフォール型開発とアジャイル開発の違いをどうこう言う必要はないかと思うが、若手の技術者は間違ってもウオーターフォール型開発のほうに行ってはダメだぞ。失敗は絶対に許されないと連呼する世界と、とっとと失敗しようぜと言う世界では、どちらが成長できるかは明らか。 https://x.com/toukatsujin/status/1863023816290762841 Xでは多方面から「いやいやいやいや、どんな世界線ですかそれ？！」と突っ込みが入った。失敗の許容度がゼロか100かってなんぞ？っていう感じ。そらそうよ。 これを受けて木村氏は「批判の中で呆れ

翻訳を担当した書籍『ソフトウェアアーキテクトのための意思決定術　リーダーシップ／技術／プロダクトマネジメントの活用』（インプレス）が明日2024年12月11日に発売となります。 本書は、2023年12月に出版されたSrinath Perera 著『Software Architecture and Decision-Making: Leveraging Leadership, Technology, and Product Management to Build Great Products』（Addison-Wesley Professional）の全訳となります。 ソフトウェアアーキテクトのための意思決定術　リーダーシップ／技術／プロダクトマネジメントの活用 作者:Srinath PereraインプレスAmazon 著者は、Apacheのオープンソース開発者として20年以上のキャリアを

ナゾロジー副編集長。 大学で研究生活を送ること10年と少し。 小説家としての活動履歴あり。 専門は生物学ですが、量子力学・社会学・医学・薬学なども担当します。 日々の記事作成は可能な限り、一次資料たる論文を元にするよう心がけています。 夢は最新科学をまとめて小学生用に本にすること。 越えたら二度と戻れない「三途の超曲面」の数理理論生の世界と死の世界は何によって別けられているのか？ 誰もは1度は考えたことがあるでしょう。 日本の仏教の考えでは、現世と来世の間は「三途の川」と呼ばれる川によって隔てられていると考えられています。 またよりカジュアルな認識では「三途の川」は生と死を隔てる境界線であり、渡り切ってしまうと2度と生の世界には戻れないとされています。 オカルト分野でも三途の川は人気であり、三途の川を渡り切る前に、先に旅立った肉親や親友に警告を受け、思い直して引き返すと病院のベッドの上だっ

タイトルのように「来月からエンジニアリングマネージャーやってくれませんか」と言われた経験が私にもあります。もう3〜4年くらい前のことです。おそらく多くのエンジニアと同じように当時の私はマネジメント業に興味がなく、マネージャーになってみたものの何から手を付ければ良いかも分からず、とりあえずチームメンバーとの1on1をセッティングしてみたりしました。 まさしく”レベル1”だった私ですが、いくらか経験を積み、今では見える景色や解像度が変わるくらいにはレベルアップした実感があります。 当時に戻れるならこんなふうにマネジメント業務に取り掛かろう、というイメージが具体的に持てるようになったので、今回はそれを言語化してみようと思います。少しレベルアップした自分から、レベル1だった当時の自分へのアドバイスのつもりで書いてみます。 ※ちなみに数人のエンジニアで構成されるチームのエンジニアリングマネージャーを

p.97 「So What?」の繰り返しによるイシューの磨き込みより ①の「地球温暖化は間違い」といった焦点の定まらない主張だと反論しようがないが、⑤にまで磨き込まれていれば、白黒はっきりさせるために何をどう検証すればよいか、見えてくる。 「So what?」の他に、「空・雨・傘」といった技法が登場するため、気づく方もいるだろうが、これはマッキンゼー＆カンパニーのコンサルになる。ただし、本書が他のマッキン本と異なるのは、完全に血肉化されているところだろう。 本書は、「コンサルティングファームの報告書のリード文に最終的に何を書くか」を丁寧に解説したものだ。だがこれは、そのまま、「どの課題に取り組めば、成果が出たといえるか（そしてそれをどう伝えるか）」という現場の問題に応用できる。 与えられた問題に疑問をいだかず、唯々諾々と取り組んでいるうちに終業時刻となる。怖いのは、頑張って残業しても終わら

2024-11-15 開発生産性Kaigi https://developer-productivity-engineering.connpass.com/event/332852/

こんにちは、バクラク事業部QAチームのteyamaguです。今回は、私たちが自動テストの整備を進める上で指針として設計した「バクラク事業部のテストピラミッド」について紹介します。このピラミッドは、効果的な自動テストを構築するために、自動テストのガイドラインとして機能しています。 バクラク事業部におけるテストピラミッドの概要 バクラク事業部では、1年前からフロントエンド・バックエンドの統合的な自動テストの整備を進めています。自動テストにおける大きな課題の1つが「どのテストで何を確認すべきか？」です。そこでバクラク事業部では、事業部全体で納得できる形のテストピラミッドを設計し、これを自動テストの指針としています。私たちは、フロントエンドとバックエンドのエンジニアと議論を重ね、フロントエンドには「テスティングトロフィー」、バックエンドには「テストピラミッド」の概念を取り入れた形で、各種テストの目

この記事では、「アジャイルはウォーターフォール時代の何を反省するのか」「アジャイルで何が改善するのか」について、個人的な考えを説明します 極端なことを言っている部分はあるので、誤解している箇所や異論があれば、やさしくコメントで教えていただければ幸いです 言いたいこと 「ウォーターフォール＝諸悪の根源」というのは誤解で、問題は請負契約にある 請負契約で「顧客の真の要望が実現されない」のは当然、インセンティブ設計がおかしい 日本版のアジャイルソフトウェア開発宣言には「外注よりも内製を」と書くべき 競争に勝つためには内製化は進む(でも内製化はとても難しい) ベンダーへ「君はアジャイルをやるか迷える立場じゃないよ」 目次 用語 ウォーターフォールは本当に諸悪の根源か？ 「ウォーターフォール＝諸悪の根源」という誤解 問題の原因は請負契約 なぜ請負契約は失敗しやすいのか？ ベンダーは「システム開発だけ