Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feederfuture-architect.github.io
Future Tech Blog - フューチャーアーキテクト
Get the latest updates from Future Tech Blog - フューチャーアーキテクト directly as they happen.
Follow now 15 followers
Latest posts
Last updated 5 days ago
コードレビューガイドラインを公開しました
5 days ago
こんにちは、村田です。有志の社員が集まってコードレビューガイドラインを作成、公開したのでご紹介します。本ガイドラインを読むにあたってコードレビューガイドラインは、既に公開しているGitブランチフロー規約にて推奨されているブランチ戦略や設定が施されていることを想定して作成されています。前提条件の章を確認の上で本編をご確認ください。ガイド作成の背景みなさんは普段どのよう心構えでレビューをしていますか？フューチャーでも当然毎日のようにたくさんのコードレビューが実施されているのですが、実際問題としてコードレビューにおける立ち振舞いはチームや人によってマチマチであることが多いです。もちろん世間でもそういうケースは多く散見されるだろうなと思います。「レビューはコミュニケーションである。コメント記載時には相手への敬意を忘れないこと」これは今回作成したガイドラインに明記したグラウンドルールです。私が一番好きなパートでもあります。改めて考えてみれば当然なのですが、この当たり前を忘れてしまっているレビューがたまに見受けられるのもまた事実。レビューのキャッチボールにおいて双方の発言や行動をあとほんの少しだけアップデートしてあげればよりスムーズなキャッチボールになるのにな…なんて場面、みなさんも多かれ少なかれ思い当たるのではないでしょうか？ゆえに今回作成したガイドラインでは、「レビュイー」および「レビュアー」それぞれの立場（役割）において推奨される行動をまとめていくスタイルをとりました。ちなみに、今回のガイドラインの中ではレビュー観点について網羅的に列挙・記載することは行っていません。開発しているプロダクトの性質・開発体制・採用技術などで観点が大きく変動するためです。レビュイーとレビュアー双方の「推奨行動」ここからは少しガイドラインの中身をご紹介します。この記事においては焦点を絞って簡単にかいつまむ形で紹介しますが、ぜひ詳細はガイド本体をご覧いただけると幸いです。レビュイーの推奨行動本章における記載はマインド面よりも実務的な内容が多いです。つまり読んだ直後から実践可能な内容が多く含まれています。プルリクエストの単位を小さくするレビュアーの負荷を必要以上に高くしてしまう行動のひとつに「複数の改修内容を単一のプルリクエストに含む」ことが挙げられます。あくまでプルリクエストは小さく保つように心がけましょう。プルリクエストのタイトルにプレフィックスを入れるプルリクエストのタイトルに命名規則をもたせることで、レビュアーの認知負荷を軽減することに繋がります。例えば新機能追加であれば feat など、決まった文言をつけるルールをチーム内で決めておくと良いでしょう。レビュアーの推奨行動レビュイーの推奨行動がより具体的なアクションについての記載だったのに対し、レビュアーの推奨行動は比較的マインドセットや心構えについての記載が多めです。読んで即実践、というよりも、読んでその意図を理解しつつ日々の行動を少しずつアップデートしていく、といった使い方をしてもらえればと思います。コメント記載時には相手への敬意を忘れないこと先の章でも触れましたが、このパートが私は一番好きです。レビューは相手を詰問する場ではありません。より良いものをチーム一丸となって作っていく、その意識を忘れないようにしましょう。指摘内容は具体的であればあるだけ良い時間に追われるレビュアーが簡素なコメントのみでレビューを終わらせてしまうケースがあると思います。もしレビュイーがその指摘から具体的な修正方針を読み取れなかった場合、結局追加のコミュニケーションラリーが発生してしまいますし、往々にしてそういった場面ではレビュイーがその指摘の意図を再度レビュアーへ伺うこと自体の心理的負荷が高くなってしまいがちです。指摘内容はできる限り具体的に記載されている方が建設的です。まとめさて、今回はコードレビューガイドラインを紹介させていただきました。このガイドラインが、皆さんのチームにおける開発体験の向上に繋がることを期待しています。ぜひご活用ください！▼ フューチャーアーキテクト コードレビューガイドラインはこちらhttps://future-architect.github.io/arch-guidelines/documents/forCodeReview/code_review.htmlガイドラインに関するご意見やフィードバックも、もちろんウェルカムです。お待ちしております。
データフローダイアグラム本の献本をいただきました
6 days ago
https://t.co/Y1dhM7EzlQ DFDの本がでる！いろんな図があったけど、DFDが1番役にたつ気がする— 渋川よしき (@shibu_jp) March 13, 2025 1月半前にツイートしたところ、プチバズりしまして、献本をいただきました。ありがとうございます。自分でもポチっていたのですが、そちらは会社の本棚にでも入れておこうと思います。データフローダイアグラムは1970年代に構造化分析の手法と一緒に考案された技法です。1990年代にはオブジェクト指向がさかんに取り上げられ、次世代のスタンダードとして喧伝されました。1997年代にはUMLが登場しました。UMLは無料やら有償のツールも開発されたり、ISOになったりかなり大きなムーブメントを起こし「図といえばこれ」という状況になっていたと思います。UMLは多種多様な図が含まれています。プログラムの構造を記述する図と、プログラムの動きを記述する図に分かれています。ERDもクラス図を使って表現する記法とかも一般化し、オブジェクト指向のコードの可視化もデータ設計も全部UML、みたいな感じでした。ただ、UMLはモデル駆動アーキテクチャ(MDA)という図を書けばシステム作れるよね、的な流れに傾倒し（結局実現しなかった）、その後アジャイルブームのおりには反動としてシンプルな図を、という流れも出て、多種多様な図の中ではシーケンス図ぐらいしか最近は周りではみないな、というのが僕の実感です。UMLの軽量版としてはC4モデルというのもありますが、日本ではそこまで話題になっていなそうです。オブジェクト指向中心に構成されたUMLを構成する多種多様な図の中には、構造化プログラミングでもお馴染みのステートチャート図はありましたが、DFDなどのデータの流れを表現する図は含まれていませんでした。本書のサブタイトルも「いにしえの技術」と入っていますし、前書きにも「DFDは過去の遺物として扱われることもあった」という背景はこんなあたりですね。しかし古いからこそ逆にDFDは役に立つDFDはオブジェクト指向の前の時代からあった素朴な手法なので、かえって現代でも応用が効いて役に立つ、という???は最近実感しているところです。フューチャー社内にはオンラインの教育コースもあり、現場でも活用されています。この技術ブログの中でも、Reactの状態管理の表現で使って見たこともあります。Reactで決められた候補から選択させるコンボボックスを実装する（サーバーアクセスつき）本書でも4章ではデータレイクとかデータウェアハウスの話題も書かれていますし、5章ではセキュリティの分析での活用ということが触れられています。僕自身、「もっとDFDは知られてもいいのにな」と思っていたところだったので、本書の登場は待望というか、むしろ僕が書きたかったのにくやしい、ぐらいの気持ちがないかというと嘘になる感じです。僕はオリジナルの1970年の原著などは読む機会がなかったのですが、本書はそのオリジナルを参照して、図の書き方の原則や、業務分析で活用する流れなどが書かれている貴重な本になっています。コンパクトにまとまった本ですし、最初の2章ぐらいを読むだけでもエッセンスは十分学べるので社内で軽く勉強会するにも良さそうです。ソフトウェアのアーキテクチャはマイクロサービスにすべき、という論もここ数年ずっと見かけますが（僕はあんまりマイクロサービス好きではないが）、マイクロサービス分割を考えている人にもDFDはよく効くと思います。国内で実践している会社の事案で、データベースのテーブルが1つ生えると「サービスの追加が必要ですね」という会話が出てサービスが生えるみたいな噂話を聞いたりもしますが、DFDを見ると、「このテーブルとこのテーブルは同時に1つのトランザクション内で同時に読み書きが必要」ということがよくわかります。分散トランザクションなるおかしなものを考えなくても、「ここで切ったら安全」という箇所が見つかりやすくなります。ここはERDだけを書いていてもわからないDFDのメリットだと思います。おや？これは普段の業務で見るDFDと違うぞ？フューチャー以外にもDFDを活用していた会社はそれなりにあるんじゃないかな、という気はしていますが、1990年のUML登場ごろからアングラ化して一般の目には触れない状態で業務で活用されてきたということで、フューチャーに限らず、それぞれの会社の中で独自進化を遂げていてもおかしくはないです。実際に僕も本書を読んでいて「あれ？だいぶ違うかも」と思うなどしました。逆にそこが新鮮というか、まだまだDFDそのものの伸び代だったり、別のものへ進化するのりしろなんじゃないかな、と思っています。DFDだけで図が必要な図が全部そろうことはないのでシーケンス図とかフローチャートといった動きを表す図、システム俯瞰図、インフラ構成図などの構成要素の図などさまざまな図と組み合わせて使うはずですが、どの図と組み合わせるかによってDFDそのものに課される役割は変わってきます。本書のサンプルだと、UMLでいうところのユースケース図的な役割も持っていそうです。確かに当時はユースケース図はなかったと思いますし「なるほどそういう活用法があるのか」というところが新鮮でした。フューチャーで書くDFDの図だとそこはないので、そもそも外部エンティティが表現されることはあまりないですし、あったとしても一番末端で積極的にインタラクションする図は見たことがなかったです。人はシステムの外の存在ではなく「画面でデータを見て意思決定をするプロセス」扱いですね。あと、L0、L1、L2といったレベルによって抽象度が異なる図を書くというのは、DFDを解説するウェブサイトにはありますし、本書でも説明されていますが、フューチャーの中では見ません。全員がコードを書けるコンサルという立場で触れるので（サブシステムごとなど分割はするが）そこそこの詳細度でいきなりズバッと書くというところも、たぶん、オリジナルのDFDとフューチャースタイルは違いがあるんだろうな、と読んでいて思いました。本書はおそらくオリジナルのDFDに忠実な説明がされていると思うので各社の発展を相対化するための物差しとして、重要な文献として後世に語り継がれるのではないかと思います。まとめ本書を読んだことで、フューチャー社内のDFDが何を工夫してどのように活用してきたのか、というのを相対的に見れるようになりました。フューチャースタイルも有志で公開しているガイドライン集にいつか入れられたらいいな、ということを思いました。そして、いつか他社のDFD図の発展がどのようになっているのかとかも世の中に出てきて、50年分の図の進化が行われると良いな、という気持ちを新たにしました。そのためにも、まだDFDに慣れ親しんでいない人たちもぜひ本書を通じてDFDというものを知って欲しいですし、知って活用している人も「自社のオリジナル要素」を知り、今後議論できる土台ができると良いなと思いました。
CursorによるAI駆動開発入門
9 days ago
本記事は、春の入門祭り2025の10本目です。はじめにSAIG（Strategic AI Group）の小橋です。生成AI関連の検証や、データ分析の業務を担当しています。生成AIを使った開発手法の進化は目を見張るものがあります。私自身は業務でAI駆動開発をすることは無いのですが、CursorやClineなどのニュースを見ない日はありません。Technology Radar の記事を2年前に書いたことを思い出したので、読み返してみました。このときは、GitHub Copilotが出始めたくらいでした。しかし最新版（2025年4月）のTechnology Radarでは、Cursor, Cline, Windsurfが登場しています。2年間で様子が随分変わったなと驚かされます。そんな中で、ある勉強会でこの本を知ったので、いい機会と思い読んでみました。AI駆動開発完全入門 ソフトウェア開発を自動化するLLMツールの操り方…が、本そのものについての紹介はあまりしません。試しに簡単なゲームアプリを自作した感想を書いてみます。この本の中では、3つのアプリケーションを作っています。最初にオセロ、次に20481、最後に音楽配信のアプリになります。ただ、単に本の通りにアプリを作成していってもブログ記事として物足りないので、オセロと2048を完了したところで別のゲームを自力で作ってみることにしました。今回はゲームを作った際の感想を書きます。作成したアプリケーション：タイピングゲーム上から落ちてくる単語をタイピングしていくゲームです。見たほうが早いと思うので、以下のスクリーンショットをご覧ください。アプリを作る手順については、最近見かけたこの記事を参考にしました。個人的 Vibe Coding...
VS CodeによるiOSアプリ開発入門〜ビルド＆ラン〜
12 days ago
はじめにこんにちは。HealthCare Innovation Group(HIG)の清水雄一郎です。VSCodeだと思っていたのですが、厳密（？）にはVS Codeであることに気づいた今日この頃です。参考画像: MicrosoftのVS Codeダウンロードサイトでの表記https://azure.microsoft.com/ja-jp/products/visual-studio-code春の入門祭り2025 10日目の記事です。SwiftにおけるiOS開発といえば、やはりXcodeを使っている方が多いと思います。ただ最近は、VS Codeに魅力的な拡張機能（特に生成AIを活用したもの）が多く、活用していきたいと思うようになりました。「Xcodeを最小限に抑えて、VS CodeでiOSアプリ開発してみたらどうなるんだろう？」という好奇心から、今回ちょっとした実験をしてみることにしました。この記事では、VS Code（周辺ツール）だけでどこまでiOSアプリ開発するためにどのような準備が必要か、検証した記録をまとめていきます。環境MacBook Air (M2...
Engineer Camp 2024 参加記：自然言語処理の研究開発で大崎から長崎へ
13 days ago
はじめにこんにちは。フューチャーのサマーインターン2024 Engineer Campに参加した、羽根田です。インターンに参加した経緯・実際に取り組んだ内容・学会参加の後日談を、インターン体験記としてまとめます。概要ここからは、私のインターン参加記を時系列順にまとめていきます。私は就活の一環として本インターンに応募し、自身の研究における専門性を活かすために「自然言語処理に関する研究開発」というテーマで参加しました。業務としてはサーベイから実験といった基礎研究に取り組み、最終的にインターンの成果を国内学会で発表することができました。詳細はそれぞれの章にまとめていきますので、気になるところだけでも読んでいただければと思います。応募から参加まで大学院修士1年の夏、私はこのインターンに参加しました。大学院生としての研究生活には少しづつ慣れてきたものの、多くのM1の方と同じように、私もまた迫りくる「就活」の二文字に背中を焼かれているような状況でした。しかし、2年後の春にはどこかの企業で働いているということの想像があまりにもつかず、とにかくこのあたりのイメージを固めたいという気持ちからインターンを探し始めました。こういった経緯もあり私はEngineer Campだけでなく、様々なインターンに乱れ撃つように応募をしていました。私の中でのインターン先の条件としては次の2つがありました。自分の自然言語処理分野へのスキルや興味を活かせること2週間以上の、ある程度長期間取り組めるものであること1つ目は私が自然言語処理の研究室に所属しており、せっかくならそこで培ったスキルがどの程度活かせるのか試してみたいという気持ちから。2つ目に関しては、比較的長期間腰を据えて参加できるものの方が自分の今後の成長につながるのではないか、という考えからです。とはいえこの2つを満たせるインターンはそう多くありません。さて次はどの企業のインターンに応募しようかと考えていたころ、ふと、春先に参加した言語処理学会にて「フューチャー」という企業がポスター発表をしていたことを思い出しました。この発表が面白かったこともあり、「ITコンサルも言語処理をやってい???んだなあ」という意外さとともに私のなかで印象に残っていました。早速調べてみるとフューチャーのサマーインターン募集ページを発見。20種類近い、かなり幅広い分野のテーマで実施しており、その中には私の希望する自然言語処理分野のテーマもありました。大規模言語モデル（LLM）を含む自然言語処理 （NLP） 技術を活用した様々な問題の解決に、メンターとなる社員と共に挑戦していただきます。国際会議を含めた論文出版、特許取得を狙う基礎研究寄りのタスクから、実社会のデータを活用したモデル構築、実際に多くの方に使われるシステム開発まで幅広いプロセスに携わっていただきます。実際に取り組むタスクについてはご本人の希望・適性に応じて相談の上で決定します。という若干ふわっとした概要に一抹の不安を抱きながらも、とりあえず応募してみることにしました。インターン本番無事に選考を通過し、晴れてインターンに参加できることとなりました。1ヵ月の長期インターンということもあり、不安な気持ちもありましたが、当初の希望通り「自然言語処理に関する研究開発」での参加ということで、かなり前向きな気持ちで臨むことができていました。ここからは実際の業務内容をメインに、1ヵ月間の具体的な過ごし方をまとめていきたいと思います。初日Engineer Campは基本的にはリモートで行われたのですが、顔合わせや手続きのために初日と最終日は大崎のオフィスに出社しました。緊張で目を回しそうな私を、いかにも”TOKYO”といった雰囲気の洒落たエントランスがお出迎え。ここから4週間のインターン生活がスタートしました。初日はまず全体説明からはじまりました。業務で用いるパソコンのセットアップや業務内容・契約の確認などを済ませているうちにあっという間にお昼休憩の時間となりました。ランチタイムでは自分以外のインターン生や社員の方とも交流しました。午後はセキュリティ講習から業務再開となり、その後受け入れ先の自然言語処理チームのメンターの方との顔合わせがありました。メンターの方々は温厚な雰囲気で話しやすく、ほっとしたことをよく覚えています。その後、オフィス内の見学やパソコンのセットアップの続きをしているうちにあっという間に終業となりました。余談ですがオフィス内にはカフェスペースやボルダリングスペース（なぜ？）などがあり、かなり面白かったです。第1週1週目は基本的に、今後の活動の方針決めや環境構築などをして過ごしました。私の参加したテーマは「自然言語処理に関する研究開発」であり、かなり研究寄りの業務でした。そのためまずはメンターの方々から提示された研究アイデアをもとに、この1か月間取り組むテーマを決定しました。テーマに関しては、基本的には提示されたものの中から選ぶ形でしたが、あくまでインターン生の興味関心が重視されていました。メンターの方と一緒にアイデアを形にしていく感覚が強く、インターンとしては特徴的な進め???だったと思います。話し合いの結果、私は「LLMを用いた文字数カウント・文字数制御」というテーマに取り組むこととなりました。第2週2週目はまず、既存研究のサーベイをすることから始まりました。私のチームはインターン生1人に対しメインメンターが1人付くという形で業務を進めることになっており、学生とメンターが3組、計6名で構成されていました。基本的にはメインメンターの方と密にやり取りをしつつ、時々チーム全体での報告会をしながら、各々の研究を進めていきます。そのため毎朝メインメンターの方とミーティングをする機会がありました。朝のミーティングでは、前日の進捗報告→次にやることを決定するというサポートを丁寧にしていただけるため、手が止まってしまうことや何をすればいいかわからなくなってしまうということはほとんどありませんでした。万が一そうなってしまった場合でも、Slackを通じてメンターの方とはいつでもコミュニケーションが取れるため、すぐに救助を要請することができました。また、毎日の朝会では、業務の話以外に雑談をすることもありました。雑談は普段のコミュニケーションがより円滑になるだけでなく、社員の方の生の声が聞けるため、就職先選びという文脈においても貴重な話を聞くチャンスでした。サーベイ結果のまとめ方のフィードバックや、研究のアイデア出しなどをもらいながら、2週目の段階で簡単な予備実験まで進めることができました。この時期には私もかなりインターン生活に慣れており、大きなトラブルなどもなく、業務を進めることができていました。始業10分前まで布団に入っているほど慣れてしまっていたときもあるほどでした。第3週3週目ではいよいよ本格的に実験を進めることになりました。基本的にはPythonでコードを書き、結果をメンターの方に共有しつつ、次の実験に向けて調整していくという流れで業務が進行していきました。2週目のサーベイからこの週の実験に至るまでは特に「研究」という色が濃かったと思います。個人的には一番熱中して作業に取り組むことができた期間でした。一方で、ただ実験をしていればよい、というわけではありませんでした。最終週にインターン参加者とメンターの参加する成果発表会が控えていたためです。そのため、インターンの研究として明確にゴールを見据えて作業することが求められていました。当然、1ヵ月という限られた期間での研究業務であるため、ある程度結果を出しつつ、最終の着地点を調整することは容易でありませんでした。しかしメンターの方と密にやり取りをしながら計画的に作業を進めることができたため、全体を通じて見通し良く作業ができたように思います。最終週の発表会に向けてスライド作成を始めながら、この週の業務を終えました。第4週最終週は発表会への準備とインターンの締め作業とで慌ただしく過ぎていきました。発表会用のスライドに関しても、メンターの方のフィードバックをもらいながら作業に取り組みました。フューチャーは会社の文化としてプレゼン???力を重視していることもあり、スライド作成についても多くの学びを得ることができました。発表会当日は他のインターン参加者の発表も聞くことができました。改めてバラエティ豊かなテーマ展開だなと感じつつ、他のインターン生の発表ぶりはかなり良い刺激になりました。最終日は大崎のオフィスに出社し、振り返りや後片付けなどを行い、私のインターンとしての研究業務は終了となりました。その他毎週、通常の業務の他にいくつかイベントもありました。1つ目は、人事の方との週次面談です。インターン業務に関する相談をはじめ、就活全般のアドバイスをもらうことができます。やはりプロとは恐ろしいもので、私が進路についてフワフワとしか考えていなかったことは瞬時に見抜かれました。即席の自己分析会が開催され、そこで進路について一緒に考えてもらいました。2つ目は社員の方による講義です。スライドの作り方やプレゼンの仕方、プロジェクトの進め方といった講義が開かれました。社員の方ならではの貴重なお話が聞ける機会だったと思います。長期インターンであることに加えリモートでの作業であったため、どうしても慣れすぎてしまうタイミングはありました。ですが、こういったイベントがスパイスのように時折挟まれるため、全体としては業務がダレにくくなっていたように感じました。1日のスケジュール10:00～11:00 メインメンターとの朝会 進捗報告とネクストアクションの決定を行います。11:00～12:00 午前中の作業 私の場合は、朝会の振り返りをしながら午後に取り組む作業をより明確に分割して整理したりしていました。12:00～13:00 お昼休憩...
チームを異動で環境が変わった後の立ち上がりについて
14 days ago
春の入門祭り2025 8日目です。はじめにはじめまして。製造・エネルギー事業部に所属しております、金森と申します。私は自動車メーカーからフューチャーへと異業種転職してきたという、少し珍しい経歴を持っております。春の入門祭りということですが、春は新しいスタートの季節です。学校や職場など、多くの人が変化の中で新たなチャレンジに向き合う時期ではないでしょうか。今回は、そんな季節にぴったりのテーマである 「チーム異動などで環境が変わった後の立ち上がり方」 についてお話ししたいと思います。転職という大きな環境の変化も経験しているからこそお伝えできる、心構えやちょっとした工夫をご紹介していきます。環境変化では「ゼロから」ではなく「編集から」始める新しいチーム、新しいプロジェクト、新しいドメイン——IT業界では異動が日常的に発生します。異動先の業務は未知の連続に見えるかもしれませんが、私は「ゼロからスタート」だとは考えないようにしています。むしろ、「編集から始める」という意識が大切だと思っています。これはどういうことかというと、「チームにある暗黙知」や「既存のプロセス」「使われている用語やツール」など、既に存在しているものにまず自分を馴染ませ、少しずつ意味づけや関わり方を変えていくという考え方です。最初から変革者のようなスタンスで入ると、摩擦が生まれやすく、信頼を得るのも難しくなります。一方で、まずは今あるやり方を尊重し、「なぜそのように運用されているのか？」を観察・理解した上で、 「もしこうだったらもっとよくなるかもしれない」といった編集者的視点を持つことで、変化の受け入れと提案のバランスの取れた動き方ができるようになります。「観察」と「共感」は、最初のタスクである異動後の最初の1〜2週間で意識しているのは、「観察」と「共感」のインストールです。特に観察では、「誰が???ーマンなのか」「どのような暗黙のルールがあるのか」「過去にどんな課題があったのか」といった点を丁寧に掴むようにしています。Slackの過去ログを読み漁ったり、タスク管理ツールの履歴を遡ったりして、表面的な情報だけでなく、空気感や歴史的な背景にまで目を向けることを大切にしています。一方で、共感はもっと感情に関わる部分です。初対面のメンバーが抱きやすい「この人は味方だろうか？ それとも違うのか？」という無意識の問いに対し、自然と「味方ですよ」と伝わるような態度を取ることが重要です。そのためには、ちょっとしたリアクションやSlackでの軽いツッコミ、さりげない称賛が意外にも効果的です。技術があるだけでは、タスクは進めどチームに馴染むことはできません。「この人と一緒に働いていて楽しい」と感じてもらうことが、結果的に生産性の向上、よりよい製品にもつながると実感しています。自信がないまま始まってもいい新しいプロジェクトに入るとき、特に異動直後や転職後は、「自分に何ができるのか？」「本当にこのチームの役に立てるのか？」という不安がつきまといます。私自身、IT業界に飛び込んだ当初は、シェルの使い方も知らず、「フロントエンド」「バックエンド」といった言葉の意味すら曖昧な状態でした。そんな中での最初のタスクは、自分の開発環境を構築すること。しかし、当たり前のように飛び交う専門用語に戸惑い、手順書の内容すら理解が追いつかず、環境構築だけで2週間もかかってしまいました。Slackではどんどんやり取りが進み、チームは次のフェーズへ向かっている。一方で自分は「まだスタートラインにも立てていないのではないか」と焦りと劣等感を感じていました。しかしあるとき、「とにかく手を動かしながら覚える」「全部を理解しようとせず、わかるところから地道に拾う」というスタンスに切り替えました。すると、知識は後からついてくること、そして何よりも「今わからないことを素直に聞けること自体が、チームの前進に役立つこともある」と気がつきました。例えば、複雑化した要件定義を読み解くとき、「これはそもそもなぜこういう仕様なのでしょうか？」と素直に聞くことで、実は誰も気づいていなかった抜け漏れが見つかったこともありました。スキルが足りないことを補うには、恐れずに聞く勇気が非常に有効だと実感しました（※もちろん自学での成長も重要ですが）最初から自信を持つ必要はありません。むしろ自信がないからこそ謙虚に学び続けられるし、気づける視点があります。それこそが、新しい環境に飛び込んだ人の大きな武器になると、今では思っています。最後に「技術ブログ」と聞くとコードや実装の話に偏りがちですが、人や組織の変化が絶えないITの世界だからこそ、「どう立ち上がるか」「どう馴染むか」という視点も、立派な技術知見だと私は考えています。これはあくまで私の個人的見解になりますが、誰かの助けの一助にでもなればと思います。次は実際に「技術的なブログ」を書けるように精進します。ではまた。
はじめてのStreamlit with Google Cloud
15 days ago
春の入門祭り2025 7日目です。こんにちは、製造・エネルギーサービス事業部の柴田です。日本の製造業・エネルギー業をDXの力で元気にすることを目指しています。企業でのDX推進においてPythonは多くの場面で活躍の場面があり、習得スキルとしても人気があります。Streamlitは、Pythonを使って簡単にインタラクティブなWebアプリケーションとして共有できるライブラリで多くの採用実績があり、Snowflakeが買収したため今後の発展も期待できます。本記事では、Google CloudのVertex AI Workbenchを活用してStreamlitアプリを開発し、Google Cloud Runにデプロイするまでの手順を詳しく解説します。ローカル環境のセットアップは不要です。前提条件Google Cloudアカウントを用意していることGoogle Cloud プロジェクトが作成済みであること全体の流れWebアプリを作成するDockerイメージをArtifact RegistryにプッシュするArtifact RegistryにプッシュしたDockerイメージをCloud...
言語処理学会 （NLP2025）参加報告
16 days ago
春の入門祭り2025 4日目です。はじめにはじめまして。フューチャー株式会社の松岡と申します。私は2024年7月に当社に入社し、現在はStrategic AI Group（SAIG）の一員として大規模言語モデル（LLM）の社会実装に取り組んでいます。私自身、LLMは大学院時代の専門領域ではありませんでしたが、LLMに興味を持ち、SAIGに所属しています。現在はNLP畑出身の専門家の方々と日々の業務と技術の研鑽に取り組んでいます。そんな私が、2025年3月10日（月）〜3月14日（金）において長崎出島メッセにて開催されました言語処理学会第31回年次大会（NLP2025）に初参加してきました。当社はプラチナスポンサーとして参加しており、私含めてSAIG7名がオンサイトで参加し、スポンサーブースでの会社紹介及びポスター発表を行いました。私は社会人1年目の新参者であるにもかかわらず、SAIG内部で参加者を募集している際に「私も参加したい」と声を上げたところ、参加できることとなりました！！快く送ってくださったSAIGの方々には感謝してもしきれません。言語処理学会とは言語処理学会はNLP分野における国内最大の学会で、毎年3月に開催されています。年次大会は今年で31回目となります。口頭発表は5会場に加えポスター発表2会場の合計7会場に分かれ実施され、最終日にはワークショップと盛りだくさんの内容です。参加者数は当日登録含まない一日目時点で2248名、発表件数777件、スポンサー数103団体と、過去最大の参加者数、発表件数、スポンサー数であり、参加していて非常に活気がある学会でした。実際に参加をしてみて、独特だなと思ったのはslackの運用です。NLP2025ではslackのワークスペースを独自に開設しており、聞きたい発表のチャンネルに入ることで、そちらから質問をすることができました。発表内容に関する議論も積極的に行われており、その議論から知見も多く得られたと同時に言語処理学会の熱気を感じ取ることができました。スポンサーブース企業ブースを出展しAI案件実績の紹介と人材募集を行いました。当社をご存じなかった方々にもアピールでき、研究についてや案件内容に用いた技術についてのディスカッションなど、大変盛り上がりま???た。主に学生の方へ向けては、会社紹介のパンフレットと共にノベルティとしてトートバッグを配布しながら、会社についての紹介をしました。たくさんの方々に来ていただき、大盛況でした。投稿論文の紹介当社は、NLP2025において著者・共著者を含めて合計5件の論文を投稿しました。本章ではこれらの5件の論文について簡単に紹介します。[P2-13]「数」に着目したLLMの多言語能力の検証この論文では、大規模言語モデル（LLM）の多言語能力を、LLMに単語や文の文字数を数えさせるカウントタスクと、指定した文字数で文を生成させる生成長制御タスクの2つの「数」に着目したタスクによって検証しました。文字列カウントタスクでは、単語のカウントは高い精度を示しましたが、文のカウントでは精度の低下が確認されました。生成長制御タスクでは、ヨーロッパ言語はヨーロッパ言語の指示で生成させる方が、アジア言語はアジア言語の指示で生成させる方が精度が高い傾向が見られました。また、中国語と日本語を生成させた場合、生成結果の平均長が指定した50文字よりも短くなる傾向がありました。さらに、日本語で指示を与えた場合、英語、スペイン語、ポルトガル語の生成結果が著しく長くなる現象が確認されました。[P2-24] Wikipediaリダイレクト情報を活用したエンティティベース質問応答データセットの構築この論文では、大規模言語モデル（LLM）がエンティティをどのように記憶しているかを調査するために、Wikipediaのリダイレクト情報を活用した新しい質問応答データセットRedirectQAを提案しています。RedirectQAでは複数の表層を考慮に入れることが可能であることが特徴で、LLMがエンティティ自体を記憶しているのか、それとも特定の表層を記憶しているのかをより詳細な分析が可能です。また、Pythiaの12Bモデルを用いて、作成したデータセットを用いて、LLMの記憶がエンティティではなく表層に紐づいているかの評価を行いました。その結果、LLMは代表的な表層を記憶している場合でも、必ずしもすべてのリダイレクト表層を記憶しているわけではないことが示されました。また、表記揺れのような表層の差異が小さい場合には、記憶が紐づきやすい傾向があることも示唆されました。[Q6-9] 日本語によるコード生成能力の正確な評価に向けてこの論文では、日本語によるコード生成能力の正確な評価を目的として複数のプログラミング言語に対応したコード生成ベンチマークであるMultiPL-Eを日本語化することで、JavaおよびC++の評価データセットJMultiPL-Eを構築し、Llama-3.1-8B-Instruct（Llama）とLlama 3.1-8Bに対して日本語で継続事前学習を行ったLlama-3.1-Swallow-8B-Instruct-v0.1（Swallow）という2つのLLMモデルを用いて、日本語でのPython、Java、C++のコード生成能力と継続事前学習がコード生成能力に与える影響を調査しました。日本語で継続事前学習を行ったSwallowでは、日本語と英語の指示文によるスコア差の縮小が確認されました。また、SwallowはJavaおよびC++において、Llamaよりも高い日本語でのコード生成能力を示しました。[Q8-18]新聞ドメインにおける大規模言語モデルの継続事前学習と下流タスクデータ量の関係この論文では、大規模言語モデルを特定のドメインに適応させるための継続事前学習の有無と教師ありファインチューニング（SFT）に用いるデータ量が性能に与える影響について、新聞ドメインの見出し生成タスクを対象に分析しています。分析では新聞記事として信濃毎日新聞株式会社が自社で執筆した紙面記事の本文、見出しを用いて、Llama-3.1-Swallow8B-v0.1、新聞記事本文で継続事前学習を行ったモデル、日本語Wikipediaで継続事前学習を行ったモデルの3つのモデルに対して見出し生成タスクへのSFTを行い、性能を評価しました。評価の結果、SFTの学習データ量によらず基本的に新聞記事本文で継続事前学習を行ったモデルの性能が高いことを確認しました。特に、SFTの学習データが50件など極端に少ない場合に継続事前学習の効果が大きい可能性が示唆されました。[D9-4] MQM-Chat:対話翻訳のための多次元品質指標この論文では、従来の翻訳評価指標では捉えきれない、曖昧さ、流行語、対話の不整合性などの問題に対処するための、対話翻訳における特有の課題を評価するための新しい指標「MQM-Chat」が提案されています。MQM-Chatは、誤訳、省略・追加、用語・固有名詞の誤り、不自然なスタイル、曖昧さ、流行語、対話の不整合性という7つのエラータイプで構成されており、特に最後の3つのエラータイプ（曖昧さ、流行語、対話の不整合性）が、対話翻訳に特化した新しい分類です。提案されたMQM-Chatを用いて、5つの機械翻訳モデルによる中英・日英の対話翻訳を評価した結果、MQM-Chatは既存のMQMよりも詳細なエラー分類を提供し、標準MQMでは捉えきれなかった対話特有の問題を明確に識別???きることが示されました。社員が選ぶNLP2025イチオシ論文の紹介本章では、NLP2025で発表された論文の中で、NLP2025に参加した7名の社員が選んだイチオシの論文を簡単に紹介します。[Q2-4]llm-jp-judge:日本語LLM-as-a-Judge評価ツールこの論文では、LLMの応答を自動評価するLLM-as-a-Judgeという手法を、日本語LLMに対して統一的に扱うためのツール「Llm-jp-judge」の提案と、評価ツールを用いた評価とメタ評価との比較を実施しています。興味深かったのは、人によって評価する場合と、評価ツールを用いるLLM（gpt-4o）による評価の比較において、LLMの方が評価を高くつける傾向にあることが示されているということです。にもかかわらず、相関値を比較してみると正確性を除き、すべての評価指標で高い相関を得られていることが結果で示されていました。LLMの自動評価ツールが注目されている中、人間よりも高い評価をつけるとはいえ、高い相関性を持つことが判明したことは今後の自動評価ツールの開発において非常に良い知見であると考え、こちらの発表を取り上げました。（松岡）[Q2-13]架空語に対するLLMの知ったかぶりの自動評価この研究では尤もらしい架空語を生成しLLMにその意味を答えさせることで、LLMが引き起こす幻覚の分析を行っています。架空語の生成では実際に存在しそうな尤もらしい架空語を生成する手法を提案しており、LLMの幻覚を誘発しやすい設定での実験を可能にしています。実験では尤もらしい架空語ほどLLMによる捏造が発生しやすいことを示しており、さらに追加実験ではRAGに近い設定で架空語に対する挙動を分析しており、たとえ架空語の意味をLLMに与えたとしても既存の知識に依存して幻覚が発生してしまう、という興味深い結果が得られています。RAGなどの文脈において専門用語などのLLMにとって未知の単語を扱うケースは頻繁に発生し、その影響を分析することは非常に重要なタスクだと考えられるため、こちらの発表を取り上げさせていただきました。（神戸）[P7-1]対照学習を用いたhallucination検出手法LLMの出力に対するhallucination検出タスクにおいて、対照学習を用いて検出モデルの学習を行うことで検出精度を向上させた研究です。hallucinationを含む文章には入力文章と矛盾する情報などが含まれることから、入力文章とは乖離する埋め込み表現を持っていると仮定し、入力文章と正例（hallucinationのない文章）との埋め込みを近づけ、負例（hallucinationを含む文章）との埋め込みを遠ざけるようなtriplet lossと、通常の分類問題のlossを組み合わせることで検出器を学習しています。既存のデータセットを用いた評価の結果、特にQAタスク・要約タスクにおけるhallucination検出精度が大きく向上したようです。LLMのhallucinationは未だ課題であるなかで、埋め込み表現に着目したアプローチで大幅な精度向上を実現していることや、特に応用範囲の広いQA・要約タスクで効果が高いことから実用的にも重要な知見であると考え挙げさせていただきました。（岸波）[Q3-25]VLMによるソフトウェア図表の理解に関する予備調査この研究では、ソフトウェア開発におけるVLMの活用を目指し、ソフトウェア図表理解能力を評価するベンチマーク「JSWEMU」を開発しました。このベンチマークは、図表の画像と設問で構成されており、描画スタイル、図表の種類ごとにVLMの図表理解能力を評価することができます。実験では、描画スタイルの正答率への影響は限定的で、図表の種類やモデルにより理解能力に差が生じるという興味深い結果が得られています。VLMの得意/不得意な領域が見えてくれば、実際の開発での活用に一歩近づくのではないかと思います。ソフトウェア開発での実応用に向けて意義のある研究だと思い、この研究を挙げさせていただきました。（加藤）[D1-5]テキストの埋め込み表現に基づくデータ増強を用いたX（旧Twitter）における日本語の皮肉検出皮肉検出のための新しいデータ増強手法の研究です。皮肉は感情分析誤りの原因となるため、検出が必要ですが、分類器の学習に十分な規模の日本語皮肉データの収集は困難です。そこで、少数のサンプルを基に、類似データを作るデータ増強が有効です。従来の増強手法は、文章の意味を表す埋め込みにノイズを加えるといった方法で微妙に異なるサンプルを作りますが、皮肉文においては「君はおめでたい人だ」を「君は喜ばしい人だ」のように変えると皮肉らしさがなくなるように、繊細なニュアンスを損なう可能性があります。そこで提案手法では、皮肉らしさに影響を与えない部分を特定し、その埋め込みにノイズを加えることで、ニュアンスを保ったままデータを増強する手法を提案しました。増強後データを利用して学習したモデルは、従来手法より高精度となりました。この研究は、レビュー分析やコミュニケーション円滑化など実社会での応用に加え、皮肉という言語現象の理解にも貢献する、意義深いものだと考え、挙げさせていただきました。（肥合）[ワークショップ1] podnikáníゴရှウ≫的聲音毎回強いメッセージを提供するかどうか模案まれたပေမယယယ့် ตอน ไป...
Google Calendar の予定を取得するMCP サーバを作ってみた
16 days ago
春の入門祭り2025 6日目です。こんにちは、CSIGの市川です。普段は FutureVuls チームで開発・カスタマーサポートの業務をしています。最近 MCP (Model Context Protocol) への注目が急速に高まっていますよね。私も気になっていた人の一人だったのですが、そんな中「エンジニアはとりあえずMCPサーバを作ってみるとよい」というポストを見かけました。「じゃあ何か作ってみるか」と思い、Google Calendar の予定を取得するための MCP...
AI時代の画像to3Dモデリング入門
19 days ago
本記事は、春の入門祭り2025の4本目です。はじめにこんにちは、最近花粉症の季節が過ぎ去りパフォーマンスが絶頂を迎えようとしている、HealthCare Innovation Group(HIG)の山本竜玄です。最近、Cursor, Cline, MCPサーバーなどなど、AI時代のツールが次々と開発されており、キャッチアップするだけでも膨大な情報量に翻弄される日々が続いています。「昨日知ったツールが今日には古くなる」といった感覚すらあります。今回は、大学時代に少し触っていて苦手としていた、3Dモデリングの世界でどのようなことができるようになっているのか、Blender MCPとMeshyという2つのAI駆動ツールを使った3Dモデル製作を試してしてみました。かつて何週間もかかっていた作業が、今やAIの力で一日でできる範囲でどれだけのものを生み出せるのか、ぜひご覧ください！1. 今回のチャレンジ内容今回チャレンジする内容は、私が社内のアイコン画像として設定している、以下の画像を3Dモデルとすることです。※このアイコン自体は入社後に私が手書きした内容なので、著作権なども問題ないはずです。（箸を持つペンギン、可愛いですよね！）今回は以下の2つのアプローチで3Dモデルを作成してみます。Blender MCP: Blenderというオープンソースの3Dモデリングソフトウェアを、LLM（Claude）を介して自然言語で操作する方法Meshy AI: テキストや画像から直接3Dモデルを生成するWebサービス最終目標は、簡単なキャラクターモデル（スキーをするペンギン）を両方の方法で作成し、その結果を比較することです。2. Blender...
GitLabのレビューにPR-Agentを組み込んでみた
20 days ago
はじめにこんにちは。フューチャーの社内セキュリティ部門、SATの髙橋です。フューチャーでは、Gitホスティング環境として、SaaSとしてのGitHubだけでなく、社内開発基盤運用チームが構築・運用している、オンプレミス版のGitLabも利用可能となっています。私が所属するSATでは、後者のGitLabを用いて開発を行っています。近頃の社内では、「Gemini、社内利用スタート！」といった記事に代表されるように、AI業務利活用の動きが本格化しています。SATでも、主にセキュリティの観点から、次々に出てくるAIサービスについて継続的に検証を進めています。そうした日々の中、開発も並行して行っていると、GitLabでも、GitHub Copilotのように、AIによるコードレビューの自動化を実現したい！ というモチベーションが湧くようになりました。いろいろと探していたところ、PR-AgentというOSSに出会いました。この記事では、GitLabに組み込んでみた実例を元に、PR-Agentでできることを紹介したいと思います。GitLabの公式AIソリューションとしては、GitLab Duoが既にエンタープライズ向けに提供されています。参考:GitLab Duoエンタープライズを提供開始本記事執筆時点（2025年4月） においては、前述の社内環境内ではまだ利用できません。PR-AgentとはPR-Agentは、大規模言語モデル(LLM)を活用してPull Requestに関連する様々なタスクを自動化・強化するために設計されたオープンソースツールです。Qodo(旧CodiumAI)によって開発が進められており、Apache 2.0ライセンスの下で公開されています。OSSの信頼性を判断する指標の1つであるGitHubでのスター数は7.6k（本記事執筆時点）と、一定の評価を得ていると言えるでしょう。なお、PR-Agentをベースにより機能が豊富なQodo Mergeというマネージドサービスもありますが、本記事での紹介は割愛します。最大の特徴は、Pull Requestを基にしたレビュー関連機能の提供に特化している点にあります。LLMへの対応状況は、こちらで確認できますが、Geminiを始め、代表的なLLMは利用可能となっています。最近公開されたモデルも随時リストアップされていることから、新型モデルへの対応が迅速に行われていることが伺えます。PR-Agentとのやり取りPR-Agentとのやり取りは、Pythonで実装されたCLIツール(後述)、またはPull Request上のコメントから以下のようなスラッシュコマンドを経由して行います。以下の情報は、本記事執筆時点（2025年4月）のものです。Describeslash_command: /describecli...
try! Swift Tokyo 2025に参加してきました！
21 days ago
はじめにHealthCare Innovation Group(HIG)1の橋本です。初めてtry! Swift Tokyo 2025に参加してきました！参加報告として、興味深かったセッションや参加して感じたことなどを共有します。try! Swift Tokyoとは公式HP の記載の通り、Swiftに関する国際カンファレンスです。今年は、2025年4月9日~11日の3日間で開催されました。イベントについてSwiftを使った開発のコツや最新の事例を求めて世界中から開発者が集います。日頃のSwiftの知識やスキルを披露し、協力しあうことを目的に、2025年4月9日 - 11日の３日間開催します！開催場所: 立川ステージガーデン会場は、昭和記念公園が隣にあったり、自然と調和した商業施設も隣接していたり、とてもリラックスできるような場所でした。（立川ステージガーデンの椅子がとても座りやすく、セッションの視聴に集中することができました。）try...