Mission Award制度は、会社の成長につながる行動を起こした社員にポイントを付与する仕組みです。

日々の業務だけでなく、自己研鑽や挑戦といった「未来への投資となる行動」を評価し、ポイントとして可視化します。

1年に一度、集めたポイントは現金化して支給されます。

具体例

例えば、以下のような行動が対象となります。

• 本を1冊読む …… 5点
• 勉強会を主催する …… 50点
• 資格試験に合格する …… 50点
• 資格試験に挑戦する（不合格でも） …… 5点

合否や成果だけでなく、「挑戦すること」そのものも評価対象です。

制度の目的

• 行動を後押しする
  学びや挑戦を“やったほうがいいこと”で終わらせず、実際の行動につなげます。
• 努力を正しく報いる
  頑張る人、行動する人が、目に見える形で報われる仕組みをつくります。
• 成長文化の醸成
  個人の成長が会社の成長につながるという考えのもと、挑戦を歓迎する文化を育てます。

会社としての想い

Mission Award制度は、「言うだけの成長」ではなく、実際に行動する人を応援する制度です。

私たちは、挑戦する人が評価される会社でありたいと考えています。
日々の小さな積み重ねや、新しい一歩を踏み出す勇気が、やがて会社全体の力になります。

行動する人が、より多くの報酬を得られる。
そのシンプルで公正な仕組みを大切にしています。

The post Mission Award制度 first appeared on 株式会社Altus-Five.

コールセンターに蓄積された応対履歴やマニュアル等の「生データ」を活用し、オペレーターの回答支援や自動応答の実現可能性を検証する生成AI（LLM）活用PoC（概念実証）を実施しました。

コールセンターの「生データ（過去ログ、マニュアル等）」を用い、検索手法、データ前処理、プロンプトエンジニアリング、さらにはFine-tuningとの比較など、10項目以上の変数について網羅的な精度評価を遂行。理論値ではない、実務転用を見据えた最適解を導き出しました。

技術スタック

• Language: Python
• LLM Orchestration: LangChain / LlamaIndex
• Evaluation Framework: Ragas
• Vector Database / Search: * Pinecone / Elasticsearch / FAISS / ChromaDB
• Development Library:
  • OpenAI API / オープンソースモデル

検証内容・プロセス

本プロジェクトでは、精度に影響を与える変数を切り分け、ABテスト形式で以下の検証を行いました。

1. ベクトルDBごとの評価：
   • Pinecone / FAISS / ChromaDB
2. ベクトルDBと検索エンジンの検証：
   • ベクトル検索 vs 全文検索（Elasticsearch） vs ハイブリッド検索の比較
3. データ構造・前処理の検証：
   • チャンク分割の有無および、最適なチャンクサイズ（文字数・意味の切れ目）の特定
   • 精度低下を招くデータの特徴抽出
   • ゴミデータ（不要な定型句・ノイズ・短すぎる報告文）のクレンジングによる精度変化の計測
   • PDF、Excel、PowerPointからの非テキスト情報抽出性能（LlamaIndex活用）の評価
4. モデルおよび学習手法の比較評価：
   • RAG（検索拡張） vs Fine-tuning（追加学習）による回答精度の検証
   • ベクトル変換（Embedding）モデルごとの検索再現率の比較
5. プロンプトエンジニアリングの深化：
   • Zero-shot / Few-shot / CoT / ReFine / HHH 等の各手法による回答品質の評価
6. 実運用シナリオに基づく評価：
   • データセット（製品カテゴリや時期）の違いによる汎用性の検証
   • 既知の問い合わせ（過去ログ存在）と未知の問い合わせに対する、AIの挙動およびハルシネーションの発生率比較

※ 精度評価には、Ragasを活用

プロジェクトの特徴

• 徹底的な「定量的評価」へのこだわり 「なんとなく動く」ではなく、どの手法が何％精度を向上させるのかを全て数値化。LlamaIndexやLangChainの機能をフル活用し、技術的な裏付けに基づいたアーキテクチャ選定を行いました。
• 生データ特有の泥臭い課題解決 現場の生データには、AIの精度を著しく下げるノイズが多く含まれます。それらを「特徴抽出」によって特定し、エンジニアリングによって解決するプロセスを確立しました。

成果

• 運用実現性に向けた「本質的課題」の提示： 検証の結果、現状のログデータの質・構造では実運用に耐えうる精度に到達しないことを定量的に証明。その上で、次期システムで目標精度を達成するために「どのようなログデータを、どう蓄積すべきか」という具体的なデータ戦略レポートを策定しました。
• 検証資産のライブラリ化（技術資産の構築）： 今回の評価に使用した膨大な検証コードを、単なる使い捨てのスクリプトで終わらせず、次期システム開発において「アプリ基盤」として即座に再利用できるよう、汎用的なライブラリとして再整備・納品しました。

Altus-Fiveの強み

単にAIツールを導入するのではなく、インフラ、DB、コード、そしてデータの性質までを垂直統合で理解し、ハックする。その姿勢があるからできる緻密な比較検証です。

新しい技術を魔法のように語るのではなく、地道な検証の積み重ねによって「ビジネスで使える道具」へと昇華させる。それが私たちのエンジニアリングの流儀です。

The post コールセンター業務における生成AI（LLM）活用PoC first appeared on 株式会社Altus-Five.

また、同じく 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.

マンション管理会社様において、入居者から寄せられる多種多様な問い合わせ（設備トラブル、契約変更、ゴミ出しルールなど）に自動回答するAIチャットボットを開発しました。

電話対応が主だったカスタマーサポートの窓口をデジタル化し、24時間365日の即時レスポンス体制を構築。入居者の利便性向上と、管理事務所の受電負荷の大幅な軽減を実現しました。

主な機能は以下の通りです：

• 自然言語による意図解釈： ユーザーの入力文から「何を知りたいか」をAIが判定し、最適な回答を提示。
• カテゴリ別FAQ： 設備故障、車庫証明、更新手続きなど、複雑な手続きをステップバイステップで案内。
• 緊急連絡先ナビゲーション： 水漏れや鍵の紛失など、緊急性の高いトピックには専用窓口を即座に提示。
• 管理画面からの回答更新： 管理会社様側でFAQの内容を随時メンテナンスできる運用機能を構築。

技術スタック

• NLU (自然言語理解): Google Dialogflow (ES/CX)
• Infrastructure (AWS):
  • Compute: AWS Fargate (Serverless Container)
  • Database: Amazon Aurora (MySQL)
  • Cache: Amazon ElastiCache for Redis
  • Search: Amazon OpenSearch Service
• Backend: Python / Django
• Frontend: Vue.js

プロジェクトの特徴

LLM（大規模言語モデル）が普及する以前の構築事例として、精度の高い「インテント（意図）設計」に重きを置いたプロジェクトです。

• 当時のAIでは最高水準の対話エンジンを使った緻密なシナリオ設計
  • 当時は現在の生成AIのように「自由に答える」ことが難しかったため、入居者が使いそうな言い回しを数千パターン学習させ、高い正答率を確保。管理会社特有の専門用語や曖昧な表現を的確に捉えるチューニングを行いました。
• 実務に即した導線設計
  • 単なるFAQ回答に留まらず、「最終的に解決したか」のアンケート取得や、解決しない場合の有人オペレーター・問い合わせフォームへのスムーズな引き継ぎフローを実装しました。
• マルチプラットフォーム対応
  • スマホのWebViewで動くようにシステムを構成し、iPhone、Andoroidに対応しました。

成果

• 自動応答へ移行： よくある質問をチャットボットが完結させることで、スタッフがより複雑な案件や現場対応に集中できる時間を創出。
• 入居者満足度の向上： 深夜・早朝でも即時に回答が得られることで、入居者のストレス軽減に貢献。
• 問い合わせデータの可視化： どのような悩みが多いかをデータ化し、マンション運営の改善に活かせる体制を実現。

Altus-Fiveの強み

私たちの真の強みは、昨今の生成AI（LLM）ブームが訪れる遥か以前から、機械学習や自然言語処理（NLP）を用いた実用的なシステムの開発・運用に深く携わってきたことにあります。

本プロジェクトのように、Dialogflowを用いた緻密なインテント（意図）設計や、OpenSearch・Redis・Auroraを組み合わせた高度な検索・データ処理基盤の構築など、AIを「単なる単体の機能」としてではなく、**「ビジネスを支える堅牢なエンタープライズシステム」**として成立させるためのノウハウを長年蓄積してきました。

この「AIの基礎体力」とも言える深い技術的理解があるからこそ、最新の生成AIを扱う際にも、その特性を正しく見極め、ハルシネーション（もっともらしい嘘）の抑制や、既存システムとの確実な連携、そしてコストパフォーマンスを最適化したインフラ設計を実現できます。

私たちは、流行の技術を追うだけでなく、これまでの歩みで得た確かな知見に基づき、お客様の課題に対して「本当に機能する解決策」を提案し、共に伴走し続けます。

The post マンション管理会社様向け チャットボット first appeared on 株式会社Altus-Five.

当社では、在宅勤務を行う社員に対して在宅勤務手当を支給しています。
在宅勤務を希望する社員は、「在宅勤務希望届」を提出することで、この手当の対象となります。

現在、当社ではほとんどの社員が在宅勤務を選択しており、日常的な働き方として在宅勤務が定着しています。

制度の目的

• 働く環境の整備支援：在宅勤務に伴う通信費や光熱費などの負担を軽減し、安心して業務に集中できる環境を整えます。
• 柔軟な働き方の実現：場所にとらわれず、それぞれのライフスタイルに合わせた働き方を選択できるようにします。

会社としての想い

私たちは、働く場所よりも成果やプロセス、チームへの貢献を大切にしています。
在宅勤務手当は、社員が自分に合った環境で力を発揮できるようにするためのサポートです。

これからも、社員一人ひとりが無理なく、安心して働き続けられる環境づくりを大切にしていきます。

The post 在宅勤務手当 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.

当社では、新入社員が業務を通じて学び、成長できるようにOJT（On-the-Job Training）制度を導入しています。
配属後は、先輩社員がOJT担当として指導役を担い、実際の業務を通じて知識・スキル・姿勢を段階的に身につけられる仕組みになっています。

制度の目的

• 早期の戦力化
  実務を通じて学ぶことで、机上の知識だけでは得られないスキルを早く身につけられます。
• 個別成長の支援
  一人ひとりに先輩社員が伴走することで、状況に合わせた丁寧なサポートが可能です。
• チーム文化の継承
  OJTを通じて、仕事の進め方やチームの価値観が自然と伝わり、組織の一体感が高まります。

会社としての想い

OJT制度は、新入社員をただ「育成する」ための仕組みではありません。
先輩から後輩へ、知識や経験をつなぐ“橋渡し”であり、会社全体の成長を加速させる仕組みです。

一人では気づけないことも、OJTを通じた対話と経験によって学ぶことができます。
私たちはこの制度を通じて、社員が安心して挑戦し、確実に成長できる環境を提供していきます。

The post OJT制度 first appeared on 株式会社Altus-Five.

当社では、厚生労働省が示す「メンター制度導入・ロールモデル普及マニュアル」を参考に、新入社員一人ひとりにメンターをつける制度を導入しています。

入社から1年間、以下の3段階を踏んで、メンターが継続的にフォローを行います。

1. 初期段階：入社直後の不安を和らげ、日常生活や職場環境への適応をサポート
2. 深化段階：社内外の人脈づくりやキャリア形成についての相談を支援
3. 解消段階：メンターから自立し、自らの力でキャリアを築く基盤を形成

メンターの役割

メンターは、直属の上司や同期とは異なる「斜め上の先輩」として、新入社員に寄り添います。
相談内容は業務に限らず、次のような幅広いテーマに対応します。

• 社内外のネットワーク構築の支援
• 将来的なキャリア形成のアドバイス
• 能力向上のための学習方法の共有
• 日常のちょっとした悩みや不安の相談

制度の目的

• 安心して働ける環境づくり：気軽に相談できる相手を持つことで、入社初期の孤立感を減らします。
• 成長の加速：業務外の学びやキャリア形成をサポートすることで、社員が早期に活躍できるようにします。
• 会社全体の活性化：異なる世代や部署のつながりが増えることで、組織全体の風通しを良くします。

会社としての想い

メンター制度は、単なる新人教育ではなく、社員一人ひとりが安心して自分らしく成長できるための伴走支援です。
「誰もが気軽に相談できる先輩がいる」環境を整えることで、新しい挑戦に安心して踏み出せるようにしたい──その想いを込めて、この制度を運用しています。

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.