はてなブックマーク

※ 凡例: ✓ = 明示的に言及、(言及) = 関連概念として触れられている、- = 言及なし ※ Reflection/Critic の Anthropic 列については、記事内で「自己批評的なループ」として触れられている Evaluator-Optimizer の概念を対応付けたもの。 ※ LangGraph 列については、引用ページ [2:1] だけでなく、ReAct エージェントや Plan-and-Execute チュートリアルなど LangGraph ドキュメント全体を含めて対応付けている。 ※ Evaluator-Optimizer は Reflection の一種とも捉えられるが、Anthropic が重視しているため独立して記載した。両者の違いは以下の通り： Reflection/Critic: 同一の LLM が自らの出力を批評し、定性的に改善する（自己批評） Eval

こんにちは、ログラスの松岡(@little_hand_s)です。 3行まとめ AIに 「レビューと改善を3回繰り返して」 と指示するだけで、アウトプットの品質が向上する 本記事では、この手法を 「セルフレビュー反復」 と呼び、ドキュメント生成でもコーディングでも活用できる シンプルな指示から始めても効果が出る。レビュー基準を育てていくことで、さらに品質が向上する はじめに AIの生成物、なかなか思った通りの品質にならないという感覚、ありませんか？ 記事を生成させたら、論理が飛躍していたり、表現が分かりにくかったり、冗長だったり...。 コードを生成したら設計に問題があったり要件を満たしていなかったり…。 結局、かなりの割合を自分で修正して結構な時間がかかってしまった、ということ、ありますよね。 そこで効果的なのが、AIに 「レビューと改善を繰り返させる」 という手法です。 本記事では、これ

こんにちは、ログラスの松岡(@little_hand_s)です 3行まとめ 「先にテストをまとめて書かせる」はTDDではない（サイクルと目的が違う） 従来のTDDでは非推奨だったが、AI時代では有効な手法に 違いを理解して使い分けることで、AI時代の開発がより効果的になる AI時代のTDDと、混乱しやすい実現方法 最近、AI開発の文脈で「TDD（Test-Driven Development：テスト駆動設計）が有効」という話をよく聞くようになりました。 ClaudeCode公式のベストプラクティスでも「TDDはエージェンティックコーディングによってさらに強力になる」と述べられており、TDDの生みの親Kent Beckも「TDDはAIエージェントと働く際のスーパーパワー」と語っています。 実際にClaudeCodeなどのAIエージェントに実装を任せると、必要なテストコードを先にまとめて生成し

株式会社ログラスは「良い景気を作ろう。」をミッションに、企業経営を推進する次世代型経営管理クラウド「Loglass 経営管理」を開発し提供しています。

こんにちは、ログラスの松岡(@little_hand_s)です 3行まとめ バッファを適切に積まないと、計画が遅延する可能性が高まる。 バッファを積みにくくする心理的バイアス(計画錯誤、過度に守備的と思われる不安)が存在する。 バイアスを打ち破るために、内訳を分解して過去の実績データに基づいて算出する「分解・ファクトベースバッファ」を使うとよい ※この記事ではアジャイル開発を例に説明しますが、考え方はウォーターフォールなど他の開発手法でも使えます。 リリース計画、遅れてない？ リリース計画を立てても、計画通りに進まないことが多いですよね。こんな経験、ありませんか？ リリース計画を立てたのに、予定より大幅に遅れる 「あと少しで終わります」が何度も繰り返される 見積もりを伝えた相手からの信頼が失われていく 原因は、見積もりに問題があることが結構あります。では、問題のある見積もりとはどんなもので

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の117週目の記事です！ 3年間連続達成まで残り42週となりました！ はじめに みなさんは、良いプロダクトを作っていくために、良い組織を作りたいと考えたことはありますか？私は常にこのことについて頭を悩ませていますが、うまくいかないことだらけでいつも心が折れてしまいそうになります。 困り果てていた私は偶然「問題解決のジレンマ」と「5000の事例から導き出した 日本企業最後の伸びしろ 人的資本経営大全」という書籍を手に取りました。そして、その書籍から得た知見をこの組織を良くしていくことに使えるのではないかと考えました。組織をよくしたいと悩んでいるそこのあなた！この記事を読むことで、新たな武器を1つ手に入れられるかもしれません。 こちらがその書籍になります。この記事を読んで興味を持った方はぜひ手にとってみ

こんにちは、ログラスの松岡(@little_hand_s)です 3行まとめ AIに質問させるときに選択肢を提示させると、回答が楽で早くなる さらに、推奨度とその理由を出力させると、その根拠を元にAIと議論できるし、納得感を持って進められる 結果、意思決定が速くなり、質も上がる AIと対話しながら開発してますか？ Claude CodeやCursorなどのAI開発ツールを使ってる人、増えてますよね。 AIが暴走しないように、不明な点を質問させてる人も多いと思います。 でも、毎回自然言語で答えるの、面倒じゃないですか？ たとえば： AI: 「バリデーション、フロントエンドとバックエンドどっちでやりますか？」 あなた: 「うーん、両方かな。セキュリティ的にバックエンドは必須で、UX的にフロントエンドも欲しいし...」（と、入力すると長い） もしどちらでバリデーションするかを決めていなかった場合、

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の113週目の記事です！ 3年間連続達成まで残り46週となりました！ はじめに AI Agentシステムを開発したいと考えたとき、「何から手をつければいいのか？」「どのツールをどの段階で使うべきか？」と悩むことはないでしょうか。 私たちのチームでは、超初期のアイデア検証から実運用に向けた精度向上の検証に至るまで、プロジェクトの成熟度に合わせてツールを使い分けることで、開発をスムーズに進めてきました。 この記事では、ありもの（Cursor）から始め、Bedrock Agentを経て、最終的にLangChainへと移行した経験を基に、AIエージェントのPoCを段階的に育てていくための3つのステップを共有します。これは、同種のライブラリ（例: LangChain vs LlamaIndex）を比較する技術

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の111週目の記事です！ 3年間連続達成まで残り48週となりました！ はじめに こんにちは、世界。 ログラスでQAエンジニアを担当している大平です。 今回は、生成AIを使って、既存機能の仕様書を作成する話になります。 コンテキストと悩みごと 現在、社内で生成AIの活用が盛り上がっており、テストに関しても、試行錯誤をしております。 試行錯誤の結果、人間がテスト分析、設計を行い、AIでテスト実装（テストケースの作成）を任せるということまでは実践レベルで利用しています。 ただ、生成AIでテスト分析、設計を実践するためには、コンテキストとして、既存機能の詳細な仕様書の情報が必要になります。仕様書の代わりにソースコードという方法もありますが、toBのプロダクトでは、複雑なビジネスコンテキストが絡み合うため

はじめに 皆さん、こんにちは。 ログラスでエンジニアをしている西代です。 今回は spec-kit を使ってみたことで見えた壁と今後の展望について話したいと思います。 背景 私は新規事業チームでエンジニアをしています。 新規事業での開発で一番求められるのは何でしょうか？ そう、スピードです。 お客様への価値提供サイクルを極限まで早め、高速で仮説検証を回す必要がある新規事業におけるプロダクト開発においてスピードは命といっても過言ではありません。 生成AIの進化により、開発スピードは格段に上がりました。 しかし、単に AI でコードを生成するだけでは、本質的なスピード向上には限界があります。 新規事業のプロダクト開発として一歩先へ進むためにはエージェンティックな開発の可能性を模索する必要がありました。 そこで私が試してみたのが 「仕様駆動開発」と Github が提供する仕様駆動開発のためのツ

こんにちは、ログラスでCTOをしております、いとひろ（@itohiro73）です。去年までは半年に1回まわってきたTech Blog Sprintが、今回はもう前回書いた記事から10ヶ月も経つということで、チーム規模の成長ぶりに驚く毎日です。 さて、ログラスは先日「Loglass AI Agents」構想を発表しました。ログラス代表布川の動画にもあるように、私たちは今、SaaSの価値を従来の形から変容させていく必要性を感じています。これまでの定量的なデータに基づいた決定論的な従来型のSaaSシステムにとどまらず、非定型なデータや不確実性の高い情報に基づいた非決定論的なタスクをAI Agentを通じて実現し、より良い意思決定に貢献するようなビジネスモデルをいかに構築していくか。私たちは今、その激動の時代の真っ只中にいます。 AIエージェントは銀の弾丸か？ この記事を読んでいるエンジニアの皆さ

クライアントの推論能力を借りて思考を伴うタスクを実装できる samplingや human in the loopとしての elicitationは面白いな〜と思っているので、よければそこだけでも見てみてください。 1. コンセプト 昨今、アプリケーション開発に変化が生じています。（toBの例で考えます。） 「ドメインエキスパートの熟練知識をシステムに写す」という面は変わっていませんが、「非定型・非決定論的判断」「実行を伴う知恵寄りの知識」のような"熟練知(Expertise)"を含め、実装に写すことができる範囲が大きく拡大しています。 従来的には 機械的（ルールベース）知識 -> プログラミング言語（ドメインモデル）という"写し"がメインだったかと思います。 上記はAI Agentの例ですが、熟練知を MCP Serverとして実装するパターンについても自分なりの考えが蓄積されたので、我

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の105週目の記事です！ 2年間連続達成まで残り1週となりました！ みなさんこんにちはお久しぶりです、QAのコタツです。なんか突然暑い日から一転、夕方が秋めいてきて最高ですね。寒暖差にお気をつけてお過ごしください。 はじめに この記事で得られる知見 この記事では弊社開発組織において品質リーダーシップを発揮してくれるエンジニアが育ってきたので、QAの私がそんな人に対してやってきたことを私の視点でご紹介したいと思っています。品質課題に悩むどなたかのヒントになれば幸いです。 想定読者 品質課題は認識しているがどのようにアプローチすればいいかわからないエンジニアの方が、課題解決方法にアクセスする糸口を見つけるヒントになる テストの手が足りない現場にいるQAの方が、中長期的な品質向上のための工夫をしていくヒン

Slack・スプシ・N1フォーカスの初期評価 まず最初に行ったのは社内検証でした。AIレビューの体験がどれだけ意味があるのか、また現実的にどの程度の精度が出るかをミニマムに検証することが目的です。 とにかくシンプルに始めました。 やったこと： Slackボットで即座に実行する環境 スプレッドシートで結果を記録・比較 社内のN1メンバーにフォーカスして一緒に評価 ドメインエキスパートではないエンジニアでは気づけない観点も多々あるため、社内のN1のドメインエキスパートと密に連携しつつも、自分自身で実際にアノテーションを行いながら、観点の抽出や獲得に努めました。 ツールは原始的でしたが、ミニマムな工数で、スピーディに改善点の発見と磨き込みを行うことができました。 雑なEvalsから始めるEval Driven Development 「最初はほとんど役に立たないような雑なEvalsを作り、それが

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の101週目の記事です！ 2年間連続達成まで残り5週となりました！ ログラスの龍島（@hryushm）です。最近は家でミニトマトを育てていましたが、この暑さで枯れてきてしまったのが悲しいです。 本記事では、参照系機能の大規模リプレイスを行った際に、Shadow Testingを導入して得られた知見を共有します。上手く活用できれば非常に強力なテスト手法だと感じたので参考になれば幸いです。 Shadow Testingとは Shadow Testingは、本番環境のトラフィックを新旧両方のシステムに流し、結果を比較検証する手法です。ユーザーへのレスポンスは旧システムから返すため、エンドユーザーへの影響なく新システムの動作を実環境で検証できます。「Dark Launch」や「Traffic Shadowi

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の100週目の記事です！ 2年間連続達成まで残り6週となりました！ はじめに こんにちは、ログラスの小林です。 最近の開発では、私も世間の流れに乗り、コードはAIアシスタント（主にClaude）に書いてもらっています。 このアシスタントの出現により高速なアウトプットが可能になりましたが、そのままプロダクションに導入できるようなコードが一発で出てくることは稀で、結局は手直しすることが多いのが実情です。 なので、私が手で実装しているときや、Claude Codeに追加指示を与えるときに考えている事を言語化して、自分好みのコードを書いてもらおうという取り組みです。 大前提として、本記事にはプロジェクトでのルールや個人的な思想も含まれますので、あらかじめご了承ください。 1. RDB集約の外に外部キーを貼ら

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の99週目の記事です！ 2年間連続達成まで残り7週となりました！ 始めに ログラスに入社してから時間が経つのも早く、もう3ヵ月経ちました。 そんな私ですが、入社して最初に作成したPRの話をしていきます。 普段からVimやLinuxを使うのが好きではありますが、それと同時に 環境構築オタク を自称している側面もあります。 オタクを自称する分、環境構築には多少のこだわりがあり、プロジェクトディレクトリに入ったら開発のための便利ツールがすぐ手元にある状態であってほしいのです。 プロジェクトに触って最初にやることというと環境構築ですが、必ずしも運用しやすい状態になっている訳ではありません。 その中でもログラスのプロダクトは環境構築がしやすい方ですが、より効率的にするためMakefileのブラッシュアップをし

2025年6月18日 12:47 - 山手線車内 ついにPixel 9 Pro Foldを手に入れて、意気揚々と電車に乗り込んだ。 窓の外の景色を眺めながら、「今日は何しよう」なんて考えていたら... あ、やばい。来週のLT発表、何も準備してない。😱 でも待てよ。最近Claude Codeでスライド生成の仕組みを整えたばかりじゃないか。 これ、もしかして電車の中でLTスライドが完成するんじゃ...？ 2025年6月18日 13:15 - まだ電車内 結論から言うと、本当に電車内でLTスライドが完成した。 こんにちは、kagaya(@ry0_kaga)です。 今回は登壇スライド作成もClaude Codeに任せたいという話です。 Claude Code × Marpのスライド生成を一度テンプレートを育てたらもう戻れなそうな雰囲気です。 スライド作成、毎回同じ作業してませんか？ 個人的にはモ

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の98週目の記事です！ 2年間連続達成まで残り8週となりました！ はじめに Claude Codeのような強力なAIエージェントが登場し、私達のソフトウェア開発に大きな変革がありました。AIエージェントを導入しはじめたものの、最初に直面する課題は「思ったよりも生産性向上に繋がらない」と感じる方はいるのではないでしょうか。 簡単な関数や定型コードの生成には大いに役立ってはいるが、難解なビジネスロジックや、複雑なビジネスフローをいざ実装しようとすると、求めていた品質よりも、やや劣るようなものが生成されることもあります。 結局、AIが生成したコードを理解し、手直ししてしまうこともあると思います。しかし、今はもはや手でコードを書くことは贅沢な時代になってきています！ 優秀なAIエージェントをうまく使いこなす

はじめに ログラスでエンジニアをしているナカムラ（@nakamura_meg)です。今回は、チームで実施した「Claude Code Week」の取り組みについて、得られた知見を共有します。 ※Claude Code関連の資料は一番下にまとめました なぜ今、強制的な変革が必要なのか Anthropic社のCEOであるダリオ・アモデイの発言が現実味を帯びてきました。 「今から3～6か月もすれば、AIがコードの90%を書いている世界になる」 「12カ月（1年）後には、ほぼすべてのコードをAIが書いている世界になるかもしれない」 ログラスには「経営管理」「人員計画」という比較的大規模な既存事業のプロダクト開発チームと、新規事業開発を行う小規模な開発チームが多数存在します。Cursor等のAI駆動開発は、これまで主に新規事業チームで大きなインパクトをもたらしていました。 しかし、私が所属する既存事

gh-asset download 1609a4fd-1243-463c-9504-b390d55c6d02 ~/Downloads => Downloading https://github.com/user-attachments/assets/1609a4fd-1243-463c-9504-b390d55c6d02 to ~/Downloads/1609a4fd-1243-463c-9504-b390d55c6d02.png => Successfully downloaded to ~/Downloads/1609a4fd-1243-463c-9504-b390d55c6d02.png ghでログインしていれば プライベートリポジトリのIssueやPR内の画像でもアクセス可能 です。 作成した背景 既存のGitHub CliにはIssueやPRのテキスト情報は取れても画像情報を取る

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の96週目の記事です！ 2年間連続達成まで残り10週となりました！ はじめに こんにちは、ログラスの村本です。 最近、チームのプロダクト品質について改善する機会があり、その文脈でBDDを導入したので、その時のお話を書こうと思います。 この記事では、BDDの導入の背景から、どのように導入して、実際どうだったかまでを紹介しようとおもいます。 同じような課題を抱えるチームの皆さんにとって、この記事が何かしらのヒントになれば幸いです☺️ BDDを導入した目的 当時のチームが抱えていた課題 ログラスもリリースから4年以上が経ち、プロダクトが成長し、これまで対応できなかったユースケースに対応できるような機能が増えてきました。 その一方で、相対的に仕様が複雑化しつつあり、特定の変更を加えたときの影響範囲の考慮漏れ

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の94週目の記事です！ 2年間連続達成まで残り12週となりました！ あと3ヶ月でテックブログ毎週更新も2年連続達成です！ はじめに こんにちはログラスのエンジニアの @Yuiiitoto です。 みなさんはCursor使っていますか？ そしてCursorのルールをどのように改善していますか？ 作りっぱなしになっていないですか？ そんなあなたに今回は 「ファイル復元トレーニング」 というルールについてのトレーニング方法をご紹介します。名前は自分が適当につけていますが、おそらく自分と同じことをやっている人は他にもいそうです。いたら連絡ください。 まずは手っ取り早くトレーニング方法を紹介します。その後はどういう観点で評価するのかなどにも触れます。 ファイル復元トレーニング 大仰な名前をつけていますが、非常

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の93週目の記事です！ 2年間連続達成まで残り13週となりました！ 自己紹介 ログラスの勝丸(@shin1988)と言います。最近はクラウド基盤チームというチームのマネージャーをやっています。今回のLoglass Tech Blog Sprintは「運用負荷」について書いてみたいと思います。 背景 最近段々と運用負荷が高まっているな実感することが増えてきました。ログラスは2020年に本番ローンチをして、もう5年ほど運用を行っています。おかげさまでお客様が増えてきて、プロダクトも大きくなってきました。新規事業も色々始まってきており、開発チームも大きくなってきました。 いわば運用の視点の価値が相対的に高まってきているタイミングです。「どういう価値を作っていくのか？」と同時に「どうやって価値を感じ続けてい

DDDは今も“武器”になるのか？ ここ1年でプロダクト開発の環境は大きく変わりました。 AIエージェントが開発現場で“当たり前”のように使われる時代になりつつあります。 そんな中で、「DDD(ドメイン駆動設計)って今の時代にも必要なの？AI時代になったらもう使わなくなるのでは？」と疑問に思う方もいるかもしれません。 私はこう思います。 DDDは、AI時代にこそレバレッジを効かせることができる、価値を届けるための“武器”になる。 (少なくとも、あと数年はね。) DDDの目的は「機能性」と「保守性」を両立させること DDDは単なる設計理論ではなく、プロダクトを継続的に改善・成長させていくための戦略です。 その本質は、以下の2点に集約されます。 ① 機能性を高めるためのモデリング ユーザーや業務の課題を理解し、抽象的な図を使ってFBサイクルを小さく・速く回すことにより、役に立つものを作れる可能性

ログラスでVPoEをしている飯田(@ysk_118)です。 この記事では私の個人的な経験からログラスにおけるコミュニティとの関わり方についての考えをお伝えできればと思います。 この記事の背景 今でこそ私個人としてはコミュニティに足を運べば知っている人がいて、「最近どうですか」から始まりいろんな雑談ができるようになったのですが、私自身がそんな状態に至るまで、そして社内の他の人に同じような体験をしてもらうまでにはそれなりの道のりがあったように感じています。 もともとこの文章は社内向けに、個人的なコミュニティとの出会いと、そこから社内に対してコミュニティ文化を根付かせるまでの思考過程を綴ったものだったのですが、社外に向けても公開するとよいのでは、という意見をもらい、体裁を整えたものという位置づけになります。 ※ログラスには2020年10月に参画しており、それ以前のお話も含みますのでご了承ください

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の 90 週目の記事です！ 2 年間連続達成まで残り 16 週となりました👑 🌱　はじめに ログラスのアプリケーション基盤チームで働いている三沢です。アプリケーション基盤では技術のキャッチアップ目的で Technology Radar を眺めて、気になったものを軽く深掘る時間を作っています。 今回は Technology Radar vol.32 (2025/04) からピックアップした、Restate について紹介したいと思います。Restate は今回 Platform 分野に新規で Assess 入りしたトピックです。ここではRestate を知らない読者を想定していて、基本的なできることについて説明します。Restate の詳細設定やデプロイ構成などは取り扱いません。 💡 Restat

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の88週目の記事です！ 2年間連続達成まで残り18週となりました！ 1. はじめに Model Context Protocol(MCP)は公式SDKを使って手軽に実装が可能です。しかしSDKでの実装は楽な反面、内部の仕組みを意識することは少ないです。この記事ではMCPの通信の仕組みを見ていき、SDKを使わずに最小限の実装のMCPサーバーを作ってみることで理解を深めたいと思います。 この記事で触れること MCPのアーキテクチャと通信の概要 JSON-RPCベースのメッセージングプロトコル TypeScriptを使った最小限のMCPサーバー実装 この記事で扱わないこと MCPの活用方法や利点 実運用向けの本格的なMCPサーバー実装（実際の運用では公式SDKやフレームワークの利用をおすすめします） 2.