また、同じく Anthropic 関連で、NewsPicks の動画で言っていたことを掻い摘んで紹介します。
コーディングのAIエージェント分野では、Claude Code が相変わらず評価が高いということで、Claude の AI モデルがコーディング方面では特に優れているというのもあるだろうけど、この CLI も高度なのだろうと思います。
そして、とうとう Claude Code を作った開発者本人は、自分ではコードを書かなくなったそうです。
この流れは、システム開発の全般で、じわじわと波及していくと思いますが、コードは AI が書くようになるから、どのように AI を動かすか、オーケストレーションとマネジメントが、人の役割として求められるようになると言ってます。

私の解釈も含めて、もう少し説明を加えると、オーケストレーションとは、例えば、AI を並列化してコードを書いた方が効率がよいわけで、それをぶつからないように配置することや、どの分野をどの AI で書かせるか采配すること、AI 間の統制をどう図るのかを設計すること、AI の出力をどのように統合していくか、などのことです。
マネジメントは、例えば、AIがダウンしてコードが作られなくなったら、それに依存する AI タスクに迂回指示するとか、難易度の高い機能部分がボトルネックになって全体の進捗が芳しくないときに、どのようにテコ入れするか指示することなどです。
今の SI の中でのマネジメントと、ここでいうマネジメントは、少し違うので、そのうち、新しい役職名で呼ばれるようになると思います。
おそらく、AIでのシステム開発方法論のようなものも、誰かが体系化し始めると思います。それもAIで書いちゃうのかな。

Anthropic では、すでに、その未来像に向かって進んでいて、この役割は、1つのことに深い知識を持つスペシャリストよりも、広い知識を持つジェネラリストが適しているので、新規の採用のすべてをジェネラリストの採用に振り切ってるそうです。

当面は、レビューをするのが人の役目と言われてるけど、オーケストレーションとマネジメントが、エンジニアの仕事になるという未来像の方が、なんだかシックリきます。

The post AI時代はジェネラリストの時代 first appeared on 株式会社Altus-Five.

GraphQL Federation によって、マイクロサービスをより細かい単位で構成することができます。
サービスを小さくできるということは、多様なシステムに組み込みやすくなります。
小さいということは、ロジックも、複雑にならずに済みます。
複雑じゃないということは、バグも少なくなるし、開発効率も高くできます。
良いこと尽くめだけど、性能についてはやや気になります。

ここまでは、サーバーサイドの話です。

フロントエンドは、どうなるかというと、通常は、1つのアプリとして実装されます。
SPAとして構築する場合は、React や Vue、Angularの1種類を選択して開発することになります。
サーバーサイドのようにマイクロに分割するのが難しいです。
難しいというか、webpack などで、1つにパッケージングしてリリースするのが一般的で、静的に統合buildするというのが定石となっています。
1つのモジュールを小さくできたときのメリットは、上記のサーバーサイドのそれと同じなので、なんとかしたいものです。

そんな悩みを解決してくれそうなのが、マイクロフロントエンド です。

フロントエンドも、マイクロに分割独立させようというものです。
webpack などがそれを実現するモジュールフェデレーションという機能を提供していて、主要ブラウザもサポートしているので、安心して舵を取ることができます。

面白いのは、React、Vue、Angularが混在して使えるという点です。
例えば、ユーザー管理マイクロサービスと対になる形でユーザー管理フロントエンドをReactで開発していて、リソース管理も対になる形でフロントエンドをVueで開発して、それを1つの画面にガッチャンコできるということ。
まぁ、大規模な開発で複数チームが混在する場合はあるだろうけど、小中規模では、あまりそこまで極端な開発をすることはないとは思います。

モジュールフェデレーションでは、ホスト側とリモート側という表現をしますが、ホストはブラウザが最初に読み込むメインの画面のことで、リモートは、include されるマイクロ化されたフロントモジュールです。
include と言ってるのは、静的にパッケージするのではなく、動的 include です。内部的には、 `<script src=”https://micro.example.com/user-service/v1.0/bundle.js“></script>` このようなコードが動的に生成されるみたいです。

ホスト側では、リモートのモジュールで発生したイベントをフックすることができるので、インターセプターのようなことができます。つまり、マイクロフロントエンドも、プラグインによる機能への介入ができるということになります。再利用性と拡張性が高くなります。

設計パターンとしては、マイクロサービスとマイクロフロントエンドとが必ずしも対になるわけではなく、おそらく、マイクロ化するモジュール単位は、サーバーサイドとフロントエンドでは異なると思います。それをうまく統合するのが、 GraphQL Federation ですが、このインターフェース設計は、とても重要で要になるのだろうと思います。

サーバーサイドもフロントエンドも小さく小さく開発できそうなことが、見えてきました。
システム構成をうまく考えると、ちょっとしたプラットフォームにもなりそうです。

The post マイクロフロントエンド first appeared on 株式会社Altus-Five.

マイクロサービスでAPIが供給されているとして、異なるマイクロサービスが複数あるときに、まるでテーブル結合するかのように、マージしてくれるもの。
クエリーだけじゃなくて、更新系もうまいこと、処理してくれる。

主要なプロダクト

Apollo Federation と WunderGraph Cosmo、GraphQL Fusion などがある。
Apollo が GraphQL Federation のデファクトスタンダートで一番導入実績があり、WunderGraph Cosmoは、最近の導入実績が急激に増えているものらしい。
Apolloは、有料版じゃないと使えない機能があったりするが、Cosmoは、全機能が利用可能で、且つ、Apolloと互換性のあるI/F仕様になっているという安心感が、その理由のようだ。
さらに、Cosmo は AWS Lambda 用に最適化されたコンポーネントがありサーバーレス化が可能なので、小規模なサービスには、持ってこいである。

マイクロサービスアーキテクチャとの親和性

マイクロサービスでは、サービスを超えてDBを共有することはせずに、専用のDBで設計する。
会員管理はRDBを使い、予約管理は DynamoDBを使うということも可能になる。

GraphQL Federation を使って、複数サービスをマージするとして、1つ1つのマイクロサービスは、小さくてシンプルなので、開発しやすい。
その一方で、フロンエンドの実装は、やや、面倒そうではある。

自社プロジェクトでの検証

自社プロダクトである「貸会議室予約管理システム」は、当初は、モノリシックに構築しようと思ったが、マイクロサービス化を推し進めることにした。
懸念されることは、マイクロサービスとして切り出したり、マイクロサービス間の整合性に頭を使わないといけないので、生産性が低下しそうなこと。
だが、それ以上に、マイクロサービスでシステムを構成することのノウハウは、AI時代だからこそ財産になると思うので、学びを優先することにした。

貸会議室の予約管理システムをマイクロサービスにすると、ユーザー管理、会員管理、リソース管理、予約管理、各種通知、・・・、単純に考えても、これだけのマイクロサービスが切り出せる。
これは、再利用できるアセットのバリエーションが増えるということでもある。
モノリシックに作り込んでしまうと、「貸会議室予約管理システム」がたった1つのアセットなので、例えば、「営業支援システム」のような開発をするときにも、「貸会議室予約管理システム」からユーザー管理機能だけを抜き出すのが面倒で、またもや「営業支援システム」用のユーザー管理機能を作り込んでしまう。ほとんど同じなのに。
それが、マイクロサービスになっていると、ユーザー管理マイクロサービスがDockerコンテナで動く状態なので、ユーザー管理機能を新たに作るという動機は起こらず、そのまま再利用する流れになる。

システムを細かくマイクロサービスで設計するときの切り札となるのが、複数サービスの Federation なので、まずは、WunderGraph Cosmo で開発を進めながら、同時に検証してみようと思う。最終的に、やっぱり Apollo に落ち着いたということになるかもしれないが。

The post GraphQL Federation とマイクロサービス first appeared on 株式会社Altus-Five.

そもそも、DB探しをしたのは、なぜかというと、エクセルで進捗管理していて、バーンダウンチャートをグラフ表示するために、数式を山ほど仕込んで、数式の意味が、どんどんわからなっていって、メンテナンス不能になったというのが、キッカケです。
いっそ、DBで管理して、エクセルからは、データソースとして DB を検索集計して、グラフ化したらよいんじゃないかと考えて、でも、DB をインストールするサーバーがないので、何かよい方法はないだろうかと、WEBを検索したのでした。

SQLite

いまさらですが、誰もが知ってる SQLite です。
ただ、これだと、チーム内の全員で共有するには、どうしたらよいんだろう・・・と、さらに検索してみると、「Lambda + EFS で SQLite をストレージに使う」という記事をよく見かけました。
そもそも、AWS使えないので却下なのだけど、この構成だと、同時アクセスがあったときに、ファイルオープンが競合して、エラーになりそうだよね。マネしない方がよいなと、読み飛ばしました。

同じく、ファイルサーバーで共有するのも、ダメなのは、言うまでもありません。

rqlite

SQLite をクラスター化してくれるツール
https://github.com/rqlite

チーム内の全員が SQLite をインストールして、rqlite でクラスター化すると同期されるから、良いんじゃないかと思ったのだけど、リーダーノード（マスターノード）を決めて、それに対して、SQLを投げないといけないので、リーダーノードのPCが起動してないと使えないという、風邪引いてもPCだけは起動しなくてはいけない不自由さで、不採用としました。

PostgreSQL

人気 NO.1 DB は、MySQLかと思いきや、今は、PostgreSQL  が一番人気なんですね。
https://www.sbbit.jp/article/cont1/155196

さらに、psql は mysql よりも、いろいろ高機能化してることを、知りました。

• 全文検索の機能がある
  • これはmysqlにもあるが。
• マテリアライズドビュー
  • ずっと何年も前から実装されてたのね、MySQLにこの機能があったらいいのに・・・と思ったことが何度あったことか。
• ベクトルDB
  • LLMには欠かせない

psql だけでも、さまざまなシステムの構築ができそうですね。

今回の用途には、使えないのは、rqlite と同じく、常に起動してないといけないからです。

見つけたら教えてください

他にも OrbitDB や、YugabyteDB なども調べてみましたが、用途には合わず、この日は、結局、最適なものを見つけられずに、終わりました。

p2pで動いてSQLが使える軽いDBがあったら、ぜひ、教えてください。

The post ちかごろの DB アレコレ first appeared on 株式会社Altus-Five.

ガリレオは 新宿三丁目駅C4出口直結、徒歩0分 という抜群のアクセスが魅力です。
雨の日でも濡れずにお越しいただけます。

会議室は30名収容可能で、リノベーションされたばかりのビル内にあり、とても清潔で快適な空間です。天井はコンクリート打ちっぱなしのデザインで、シンプルながらもスタイリッシュな雰囲気を演出しています。

さらに、プロジェクターやWi-Fiをはじめ、会議やセミナーに必要な設備を完備。大切な打ち合わせや研修、勉強会など、さまざまな用途にご利用いただけます。

当社はこれまでシステム開発を中心に事業を展開してきましたが、新たな挑戦として貸会議室事業に踏み出しました。ガリレオを通じて、地域の皆さまや企業活動に貢献できる場を提供してまいります。

新宿での会議やイベントには、ぜひ「ガリレオ」をご活用ください。

ご利用方法は、以下で紹介しています。

The post 貸会議室「ガリレオ」オープンのお知らせ first appeared on 株式会社Altus-Five.

ラウンドロビン設計は、3人以上がいる開発で、何かを設計するときに、いったん、全員が各々でラフスケッチをするところから始めて、スケッチを隣の人に回して1回転させて、自分の案との違いを確認し、そこに追加で自分のアイデアを書き加えて、さらに、1回転させて・・・・といくことを繰り返す設計手法です。

自分のアイデアと他の人のアイデアが組み合わさって、1人では考えつかなった設計に変化していって、短時間で洗練させられるようです。
原典なのかは不明だけと、「Design It! ―プログラマーのためのアーキテクティング入門」の第9章”アーキテクチャデザインスタジオを開く”で紹介されています。
この本によると、ワークショップ形式で全員で取り組んで90分で完成させると書かれてます。時間制限を設けることも大事なようです。
90分で終わるなら、普段の開発の中でも、取り入れてもいいかな。
設計レビューも不要だし、チーム内に新人の人が居ると教育にもなるし、良さそうです。
ただ、アイデアが発散したときに収束させるのが厄介かもしれないけど。

ラウンドロビンレビューは、レビューを複数名で、役割分担するのだけど、例えば以下のような役割で分担するとします。

• 仕様面が正しく実装されているかをレビューする役割
• テスタビリティをチェックする役割
• メンテナンス性をチェックする役割
• SOLID原則などの実装合理性や実装デザイン性をチェックする役割

役割をさらに、細かくして、1人複数の役割を分担してもよいと思います。
仕様面のチェックは、DB観点と画面観点で分けても良いし、SOLID原則は、それこそ、S/O/L/I/Dで分けても良いという具合に。
これのよいところは、大きいプルリク全体をマルっとレビューするときの気持ち的な負担が軽くなるように思います。
ただし、レビュー指摘が錯綜する可能性がありそうなので、それは、デメリットの1つかもしれないです。
本来、このラウンドロビンレビューは、役割を強制的に割り当てるので、メンバーのレベルが同程度のときに有効とされるのだけど、レベルが違う人が入っても、2～3回転させるルールにすると、弱いパートが補完されるし、教育観点が加わるので、それアリかもと思いました。
こちらは、WEBで記事を漁っていて見つけたものです。

アイデア出しのフレームワークにブレインライティングというのがありますが、ぐるぐる回すというところが、ちょっと似てるなと思いました。
ブレインライティングもやってみると、ちょっと面白いので、アイデアを量産しないといけない場面があったら、WEBでやり方を検索してみてください。

モブプロもラウンドロビンだし、他にも普段の仕事の中で、”ラウンドロビン○○” してみると良いかもです。

腕を胸の前で糸巻きするように回しながら、「ぐるぐる戦法」と言ってみるのも良いと思います。

The post ぐるぐる戦法 first appeared on 株式会社Altus-Five.

チームのメンバー構成とメンバーのスキルレベルによって、アウトプットできる成果物の量は異なります。 ベテラン1人とキャリア1年目、キャリア3年目の人のチームが目指すべき生産性を、定量的な絶対値で目標設定する場合、 ベテラン3人構成でのアウトプット量を “そうあるべきライン” として目指さないといけないのだろうか？ でも、その目標をクリアできるのは、キャリアの浅い人の成長を待つことになるので、何年か掛かります。 チーム構成は時と場合によって、さまざまなので、絶対的な指標は、あまり機能しないことは、想像に易いと思います。 そもそも絶対値の求め方というか計算式をどうするのかも難解です。

そこで、相対的なベロシティの方が有効となるわけです。 ベテラン1人とキャリア1年目、キャリア3年目で、現在のベロシティは 35 ポイントと出ているなら、 それを維持するか、少し上回るように、目標設定すると、達成感も得られるようになります。

気を付けないといけないのは、ストーリーポイントの見積でのブレでしょうか。 ついつい甘い見積になってしまう傾向のあるチームでも、常に甘い見積を出している場合には、相対的なベロシティは指標となり得ます。 しかし、甘かったり、辛かったりと、毎回見積がブレる場合には、ベロシティもブレるので、見積精度の観測も同時にやった方がよいのだろうと思います。

さて、ベロシティというとスクラムじゃないと使えないと思ってる人はいないだろうか？ 実は、私は、そう思ってました。 でも、どうやら、スクラムじゃなくても、ストーリーポイントでの見積とベロシティで生産性を計測できるようです。 イテレーションで期間を区切ってない開発の場合、計測時点で、タスクが完了していないこともあります。 その場合には、ストーリーポイントを、ベロシティ計測時点の進捗率で、換算します。 タスクA のストーリーポイントが 8 ポイントだとして、計測期間終了時の進捗率が 50% だとしたら、4ポイントのタスクに取り組んだことにして、 ベロシティを計算するということです。

スクラム以外でも、ベロシティを生産性指標に活用にしてみてはいかがでしょうか？

※今回の記事には、こちらの記事を参考にしました。 → アジャイル開発でストーリーポイントを見積もる手順

The post アジャイル開発（アジャイル風も含む）での生産性の計測 first appeared on 株式会社Altus-Five.

9時に起床して10時に仕事を始めると、12時には、ゴールデンタイムが終わるってことか、なんだか、もったいない。 10時に起床して即仕事を始めたら、ゴールデンタイムの1時間を昼休みで消費してしまってることになる。

どっちにしても、だいたいの人は、午前中いっぱいはゴールデンタイムなのだと思うけど、その時間に朝会とかをやってるのは、どうなんだろう？ 朝会じゃなくて夕会をやる方がいいのかもしれない。

脳の回復に関することを少し、紹介します。

• パワーナップ昼寝ですね。20分くらいの仮眠をとると、そのあとの効率がずいぶんと回復するようだ。 実際、昼寝すると、頭がスッキリした気になるので、効果はあるのだろう。
• マイクロナップ1分間、目をつぶる。 脳が処理してる情報の8割が視覚によるもので、それを遮ることで、脳は、ずいぶんと休憩できるのだそうだ。 会議に入る直前の1分間でマイクロナップすると、会議中の居眠りを予防できるとあった。

時間管理術を、少し紹介します。

• ポモドーロテクニック25分集中して、5分休憩するのを繰り返すのだけど、ポモドーロテクニックでも、休憩の5分は、寝るのが一番よいとあった。
• フロータイムテクニックポモドーロをアレンジしたもので、25分と5分という刻みを自分にあった時間でやるというもの。
  自分のちょうどよい時間を見つけるために、実際に作業を始めて集中できなくなるまでの時間と、休憩して再びやる気が戻って再開するまでの時間を記録して、自分のちょうどよい時間を把握するというやり方。

私は、6時頃に起きてるので、9時頃になるとゴールデンタイムが終わるってことか、確かにこの3時間は、集中できてる気がする。 そして、10時になると、いくつかのプロジェクトの朝会をハシゴして午前中が終わるのだけど、あぁ、もう10時かと、寂しさが過るのは、ゴールデンタイムが終わったからなのかもしれない。 会議や雑多なことに追われると、仕事が手につかなくなることがあるが、あれも、脳が疲れて機能しなくなった状態か。

パワーナップとマイクロナップを試してみようと思います。

みなさんも、脳の疲れを回復させながら効率よく仕事していきましょう！

The post 朝の3時間は脳のゴールデンタイム first appeared on 株式会社Altus-Five.

このプロジェクトでは、主に Python で LangChain、LlamaIndex、Ragas などを活用して開発検証を行っています。 今、LLM を使った開発は、このあたりのライブラリを使うのが主流であろうと思います。

私の役割は、調査のシナリオ立案と結果のレポート作成だったので、コードを書く機会は無く、 そのため、LLM 関連のプログラムを書くときの大変さとか難易度を肌感覚で掴めておらず、 やや、もどかしさを感じていたので、サンデープログラミングで実装の体験をすることにしました。

業務では、Python 版の LangChain を使用していましたが、日曜大工では、JavaScript版の LangChain を試してみることにしました。 さらに、LangChain は昨年あたりから LCEL という機能を推進しているので、これも試します。

PoC 案件と同じものを作っても面白くないので、私の手習いの実装テーマは「MD の英文テキストを日本語に翻訳する cli ツール」とします。そして、LangChain のマニュアルが、まだ日本語訳がないので、これを翻訳します。

LangChain のドキュメントは、コードのリポジトリの中に一緒にコミットされていて、主に MD と Jupyterノートブックで書かれています。 それらを、Docusaurus というドキュメントシステムで公開するようになっています。 手習いのゴールは、この英文のドキュメントを日本語訳して、Docusaurus でビルドして、日本語でドキュメントシステムが表示されるところまでとします。

Markdown パーサー

ChatGPT に MD のテキストを丸々投げると、max_token を超えることが懸念されるので、分割して翻訳します。 単純に文字数で chunk 分割すると、翻訳結果がおかしくなるので、文単位で分割するのは必須要件となります。 このために、MD ファイルを抽象構文木（AST）に変換し、文の正確な抽出を行います。 この変換には、 remark を使いました。

実際、MD を AST に変換してみると、どのドキュメントも、適度に空行が入っているので、AST の 1 つのテキストノードの中に、 max_token を超えるほどの長い文は、ほとんどありませんでした。 また、コードのブロックもノードタイプで識別できるので、翻訳対象から除外できます。 テストした中では、唯一、MDのテーブルが、テーブル全体で1つのテキストになるので、これだけは、改行を区切り文字として、分割する必要がありました。

翻訳処理

本記事の主題です。 LangChain を使って、 LCEL （LangChain Expression Language）で翻訳処理を実装します。

その前に、翻訳処理の仕様を簡単に説明すると、最初のプロンプトで英文から日本語に翻訳して、その結果を受けて、その翻訳が正しいかを、添削するプロンプトを実行します。添削結果には、翻訳の正確さを数値で出力するように指示して、その数値が閾値を超えるまで、添削を繰り返します。

最初の英文から日本語への翻訳 Chain

const etojPrompt = await DEFAULT_ETOJ_PROMPT;
const etojOutput = (await etojPrompt
  .pipe(model)
  .pipe(new JsonOutputParser())
  .withRetry({ stopAfterAttempt: MAX_LLM_RETRY_ATTEMPTS })
  .invoke(etojInput)) as EtojOutput;

この手習いをやり始めたときには、LCELじゃなくて、従来方式で実装していたのですが、 翻訳されたマニュアルを読んでいるうちに、LCEL で実装することが推奨されていることを知ったので、 せっかくなので、 LCEL での実装に切り替えてみました。 やってることは変わらないのだけど、コードの見通しがよくなったような気がします。

Python で実装すると、たぶん、こんな感じだと思います。

model = ChatOpenAI()
etojPrompt = ChatPromptTemplate.from_template(DEFAULT_ETOJ_PROMPT)
chain = etojPrompt | model | JsonOutputParser()
etojOutput = chain.invoke(etojInput)

| か pipe() かの違いはあるけど、機能的には同じです。

余談ですが、プロンプトの実装で、Python 版では、jinja2 のテンプレートエンジンを使えるんですが、 js 版では、テンプレートエンジンが使えません。 プロンプトの文字列をリアクティブに変数展開したいことがあるので ejs でもよいのでテンプレートエンジンを使えるようにしてほしいです。 今回の実装では、添削を何回か繰り返すときに、前に添削した内容と同じ添削結果を返してくることがあったので、 過去の添削結果を、添削用プロンプトの中に含めて、同じ添削結果を返さないように指示するのですが、 その処理の実装をしているときに、python だったら jinja2 が使えるのにな・・・と思いました。

添削 Chain

最初のチェーンと添削チェーンも、1つの LCEL でつなげた実装にしようかとも思ったのだけど、 正確さが閾値を超えたら終了する仕様を実装するには、カスタムチェーンを作る必要がありそうなので、 そこまではやらずに、チェーンを分けて、ループさせることにしました。

const proofreadChain = proofreadPrompt
  .pipe(model)
  .pipe(new JsonOutputParser())
  .withRetry({ stopAfterAttempt: MAX_LLM_RETRY_ATTEMPTS });

const proofreadInput: ProofreadInput = {
  ...etojInput,
  ...etojOutput,
  histories: [
    { proofreadText: etojOutput.ja, correctness: 0.0, error: '' },
  ],
};
let answer = '';
for (let i = 0; i < MAX_PROOFREAD_ATTEMPTS; i++) {
  const proofreadOutput = (await proofreadChain
    .invoke(proofreadInput)) as ProofreadOutput;
  answer = proofreadOutput.proofreadText;
  if (proofreadOutput.correctness >= TRANSLATION_CORRECTNESS_THRESHOLD) {
    break;
  }
  proofreadInput.histories.push(proofreadOutput);
}
return answer;

LCEL の batch で、効率の良い並列処理を実行するには、カスタムな添削チェーンで、1本につなげた方がよいです。

まとめ

手習いのゴールとした LangChain のマニュアルを日本語訳してドキュメントシステムをローカルで動かすのは、うまく行きました。 LangChain のドキュメントシステムは、amazon linux 2 で実行するようになっていて、ビルドも、それ用になっているので、 開発環境とした ubuntu の devcontainer でビルドできるようにするのに、ひと手間必要でした。

さて、LCEL についてですが、慣れるまで、少し時間がかかりました。 もう少し “らしさ” を出せるかな・・・と思っていたのだけど、 LCEL にするために知恵を絞らないといけないのが、やや面倒だなと感じましたが、おそらく、その知恵を絞ることで、コードが改善されて可読性が上がるのかもしれないです。 でも、LCEL だろうが、LCEL じゃなかろうが、やってることは変わらないので、コスト見合いで、コダワリ過ぎには注意した方がよいかもしれません。

それから、反省点というか注意点ですが、実行時間と、APIの使用料が想定外にかかりました。 LangChain のマニュアルは、1000 ドキュメントくらいあって、何度か止まって再起動していて、 実行するだけで、トータルで 3 日以上かかり、API の利用料が、$500 ちょっとでした。 1ドキュメントを翻訳するのに $0.5 です。

$0.5 が高いか安いかは、人によると思いますが、私の場合、日本語の技術情報が少ない開発をするときに、 英語のマニュアルを、クラウドソーシングなどで翻訳してもらって、 日本語でザックリと読んで概略を掴んでから開発に入ることがあるのですが、 クラウドソーシングに比べると、全然、安いので、個人の財布で実行しようとは思いませんが、 今回作成した翻訳ツールは、実際に使っていこうと思います。

WEB で参照できる英文のマニュアルなら、Google 翻訳で、無料で翻訳することができますが、 日本語で検索しても、ヒットしないので、あらかじめ日本語訳しておくことは、有用だと思います。

少し面白そうな使い道としては、翻訳した MD ファイルを独自に追記編集するとかも有りだと思います。 開発を始めたばかりのときに読んだマニュアルは、まだ、十分に理解できないことがありますが、 開発が進んで、実際に動作を確認していくと、マニュアルに記載されている内容が、理解できたりします。 このときに、おらがチームのマニュアルに、理解の手助けになるようなメモを追加するとか、 実プロジェクトのコード片を追記したりして、独自にドキュメントを育てていくと、Google翻訳よりも、価値があるように思います。

実装した翻訳ツールは、こちらで公開しています。使ってみたい方は、APIの費用に注意して、ご利用なさってください。

最後に、このツールを追加改良したいことを書いておきます。

改良点

• 過去の翻訳結果をコンテキストとして加えてプロンプトを作成する翻訳した結果を RAG にして refine 法でプロンプトを作成すると、一貫性のある翻訳ができるようになるのではないかと思います。
• 並列化バッチ処理なので、 LCEL の batch で並列化したいです。実行時間も短縮化できますし。
• chatbot翻訳されたマニュアルで RAG を駆使して chatbot を動かしたいです。
• rst の翻訳LlamaIndex のマニュアルも翻訳しようとしたら、こちらは rst （reStructuredText）で書かれていました。 Sphinx です。python の docutils でパースする必要があります。

MIT で公開しているので、有志のご参加をお待ちしています。

The post js 版の LangChain で LCEL を試す first appeared on 株式会社Altus-Five.

ADR とは、アーキテクチャ上の設計判断を記録したもので、MD等の軽量なドキュメント形式で蓄積しようというものです。 記事中でも、参照がありますが、Michael Nygard氏がブログで紹介したところから広まっていったようです。 この記事も、Google翻訳して、読んでみることをお勧めします。

アジャイル開発では、体系的にまとめられた大きなドキュメントを作成することは行いません。 ドキュメントをまったく作成しないわけではないけれども、必要最小限なドキュメント構成になります。

この場合に問題になるのが、例えば、プロジェクトに新しく誰かが参加したときです。

システムの仕様だけではなく、過去の経緯なども、知らないので、アーキテクチャーの変更に迫られたときに、 過去の経緯に関係なく、盲目的に変更するしかありません。 このような変更は、地雷を踏んでしまったり、過去の問題が再燃する可能性があったり、とても怖い決断になります。

ADR は、なぜそのアーキテクチャーが必要なんだっけ？とかの導入経緯や、どういう影響があるんだっけ？を記録として残していきます。 体系的で重厚なドキュメントを書くのではなくて、なぜその決定がなされたかを記録します。

このやり方は、ThoughtWorks社のMartin Fowler氏も、technology radar で評価していました。 そして、現在の radar では、ADR を拡張して設計変更も同じ方式で管理する 「Design system decision records」（設計・デシジョン・レコード） を評価しています。

Google や Amazon も取り入れています。

• https://cloud.google.com/architecture/architecture-decision-records?hl=ja
• https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html
• https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/appendix.html

そして、この ADR のドキュメントは、その検討がされていた一時期だけ更新されるドキュメントで、それ以降のメンテナンスは、不要だというのがいいです。 後々、同じ領域の設計話題が出たときには、新しい ADR を作成して、過去の ADR へのリンクを張るだけで、過去の決定をたどることが可能となります。

直観的に、これは良いなと感じました。そして、アーキテクチャーの枠を超えて設計変更の経緯を追跡する「設計・デシジョン・レコード」がもっといいです。 設計書は書かないけど、設計変更の経緯は残すというのは、継続的なエンハンスの開発がされているアジャイルのプロジェクトに最適です。

サンプルです。例えば docs/ADR/adr-NNNN.md で追加していきます。

## Title
勤怠管理システムにおけるクラウドベース認証サービスの採用

## Status
Proposal

## Date
2024-01-26

## Context
既存の勤怠管理システムは、オンプレミスでの認証メカニズムを使用している。
しかし、リモートワークの増加とスケーラビリティの要求により、より柔軟かつセキュアな認証システムが求められている。

## Decision
AWS Cognitoのようなクラウドベースの認証サービスを導入して、ユーザー認証プロセスを管理する。

## Consequences
### Positive
スケーラビリティと可用性が向上し、リモートワークに対応しやすくなる。

### Negative
既存のシステムとの統合には初期コストがかかり、スタッフのトレーニングが必要。

## Compliance
- 新しい認証プロセスはGDPRおよびその他のデータ保護法規に準拠する必要がある。

## Notes
- Author: hoge
- Version: 0.1
- Changelog:
    - 0.1: Initial proposed version

とても、シンプルです。ADR に関して、このサンプルを読む以上の学習は不要です。独自にルールを追加して運営するのも寛容です。

ドキュメントがなくて、システムの仕様理解が進まないというプロジェクトは、たくさんあります。 だからと言って、今から、体系的にドキュメントを作れるわけでもないので、特段、対応策が講じられないのが現状ですよね。作ってしまうとメンテナンスに工数を取られるし。

でも、ADR なら、すぐに始められるし、とてもライトで強力な施策になるのではないでしょうか？

うちの会社の開発標準としても、組み込んで然るべきな気がしてます。

The post アーキテクチャー設計の意思決定を効率的に記録する「ADR」の導入 first appeared on 株式会社Altus-Five.