本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「MicrosoftのOSSにコントリビュートした話」を再編集したものです。
―――――はじめに―――――
株式会社FIXER採用担当の澤田です。
FIXERでは、昨年から三重大学と提携し、長期インターンシップを実施しています。
今年は1名の学生を迎え、実業務を約二か月間体験していただきました。最終日に取り組みの様子をブログに書いていただきましたので、その内容を代筆いたします。
以下インターン生によるブログになります。ご覧ください。
――――――――――――――
はじめまして!
FIXERインターン生の杉井位次と申します。
現在は大学4年生で機械工学を専攻しながら、趣味でSwift・Flutterでのモバイルアプリ開発やReact・RubyでのWebサービスを開発しています。
約2ヶ月の間、週5で四日市事業所に通いインターン生として生成AIについての技術調査を行なっていました。その結果としてタイトルにもある通りマイクロソフトのOSSにコントリビュートすることができたので振り返っていきたいと思います。
OSSへのコントリビュートに興味を持っいる方に少しでも参考になれば幸いです。
はじめに
OSSとは
OSS(Open Source Software)とは、ソースコードが公開されていて自由に利用、改変、再配布ができるソフトウェアのことを指します。開発コストの削減や複数開発者からの改良があり、OSSを利用する技術者だけでなく企業にとってもメリットがあります。 具体的な例では、LinuxやFlutter・ReactなどもOSSで開発されています。
コントリビュートとは
OSSへのコントリビュートとは、オープンソースプロジェクトに対して何かしら貢献することを指します。 貢献の方法としては、ドキュメントの更新やバグ報告、機能開発などがあります。他にもコミュニティでユーザーに対してサポートやアドバイスを提供することでもプロジェクトに貢献できます。
どんなOSSにコントリビュートしたの
インターンの中で技術調査・検証を行っていたSemantic KernelというOSSにコントリビュートすることになりました。
Semantic KernelはMicrosoftが開発する大規模言語モデル(LLM)を簡単にアプリに統合することができるSDKです。
公式から引用 公式リポジトリ
Semantic Kernel is an SDK that integrates Large Language Models (LLMs) like OpenAI, Azure OpenAI, and Hugging Face with conventional programming languages like C#, Python, and Java. Semantic Kernel achieves this by allowing you to define plugins that can be chained together in just a few lines of code.
興味がある方は海老原さんがご紹介していた下の記事をご覧ください!
未来が来た!!Semantic KernelでAIのタスク実行計画を自動立案!
Semantic KernelはLLM関連のプロジェクトなこともあり、急速に開発が進められ破壊的変更を含むアップデートが頻繁に実施されています。そのため技術検証をする上で、GitHub上で開発状況を確認したり、追加された機能の実装を調べるのが欠かせません。
Semantic Kernel バージョン履歴 (.Net版)
日付 | バージョン | URL |
2023/12/07 | 1.0.0-rc3 | GitHub |
2023/12/14 | 1.0.0-rc4 | GitHub |
2023/12/19 | 1.0.1 | GitHub |
2024/01/16 | 1.1.0 | GitHub |
2024/01/25 | 1.2.0 | GitHub |
2024/02/01 | 1.3.0 | GitHub |
初のOSSコントリビュート
きっかけ
Ver 1.1.0からAzure OpenAI のJSON Modeが使えるようになる機能が追加されたので技術検証を行なっていたところ、バグを発見しました。
JSON Modeは、LLMモデルからの返答がJSON形式で返ってくることが保証されるというものです。今までJSON形式で出力してほしい時は、プロンプトエンジニアリングを用いたりFunction Callingの引数がJSONで返ってくる性質を利用したりと何かと手間がかかっていました。 Semantic KernelでのJSON Modeの使用方法は簡単で、プロンプトの設定を行うexecution_settingsでresponse_format={ "type": "json_object" }プロパティを追加するだけです。
が、実際はそんなことありませんでした。
不具合の原因を調査してみると、想定外の型変換によってJSON Modeの有効化がされないままOpenAIへリクエストが送られていることが分かりました。
すぐにこのバグに関するissue・PRを探しても見つかりませんでした。 つまり、今このバグに気がついているのは、自分だけかもしれない。
もうこれはコントリビュートするしかありません。
推しからのリプ
コントリビュートすると決まれば、まずはissueを立ててバグの報告します。 OSSでは、日々大量のissueが立てられており開発チームも対応に追われています。 開発チームの負担を減らすためにも、issueのフォーマットとコントリビュート規約を確認することが重要です。(雑なissueは何も反応してもらえない場合がある)
How to conribute to Semantc Kernel
今回のissueではバグの説明と再現方法に加えて、バグの発生理由も併せて報告しました。
.Net: Setting json_object mode in execution_settings does not enable JSON mode as expected #4719
いきなりバグ修正のPRを出しても、修正の方向性が開発の方向性と違う場合があるのでスレッドで相談する必要があります。
今回のバグの原因は、本家Azure OpenAIのSDKではJSON Modeがまだβ機能であることを配慮して実装されていたことが関係していました。その実装の方向性は変えないように、修正方法を提案をしてみました。
issueを立てて数日後、提案に対して開発チームから返信をもらいPRを作成することになりました!Semantic KernelのテックブログやGitHubで毎日見かけていたエンジニアから返信してもらえたことはとても感動します。
例えるなら、毎日テレビに出ている推しからSNSでリプをもらうようなものです。推しに認知されたら誰だって嬉しくなっちゃいますね
いざPR
推しに提案した修正内容で早速PRを作ります。
PRの作る手順はこんな感じです。
1.OSSのリポジトリをフォークする
2.フォークしたリポジトリをクローン
3.ブランチを切ってCommit,Push
PRを作る際もフォーマットに従って、PRの背景と変更内容の詳細を書く必要があります。 .Net: Fix bug to allow activation of JSON mode through execution_settings #4774
PRを作成したら自動で、テストやフォーマットチェックが実行されます。この時に問題があれば、修正commitしてレビューを待ちましょう。
今回のPRは条件分岐を追加するだけのバグ修正だったので不要でしたが、PRの内容によってはテストを追加する必要がある場合があります。そういった内容も含めて開発チームと相談しながらコントリビュートするのが良さそうですね。
コントリビュートして感じたメリット
実はこのブログの執筆時点(PRを出して4日)ではまだ、レビュー待ちでマージもされていないのでバグ修正に貢献できたかどうかは分かりません。。 ただ、コントリビュートをする過程で感じたメリットがあったので書いておきます。
英語の勉強になる
OSSのドキュメントはほとんどが英語で書かれています。ドキュメント以外でもissue・PRを見てみると、参考書などではみたことがない表現も多く使われていて、生きた英語を大量に浴びることができます。またissueとPRの内容は論理的に問題や原因を説明する必要があり、いざ英語で考えようと思うとかなり大変です。
あと海外のエンジニアと英語でやりとりした経験は自信になりました。
コードのコンテキストを読む力がつく
バグの原因調査や追加された機能の仕様を調査する中で、色々なGitHub上の情報を確認していました。そのおかげでコントリビュートしたOSSをより理解することに繋がったと思います。 併せてGitHubでコードを確認する際に個人的に感動したTipsも紹介します。
github.dev Web ベース エディター
たまたまショートカットキーを押して見つけたのですが、github.devという機能がありました。GitHubのβプレビュー機能として、Web上でVSCodeが利用できるようになります。
可読性も上がり、拡張機能や「定義へ移動」なども利用できるのが便利でした。 ローカルにクローンしていないプロジェクトのコードを確認するときに使えそうですね。
終わりに
今回の経験から、動かないと嘆くのではなく、自分で修正する姿勢を持つことは、OSSに限らず何事にも活かせる大事な考え方だなと実感しました。
そしてOSSへのコントリビュートのハードルも下がったので、今後も挑戦していこう思います!
この連載の記事
-
TECH
Github Copilot Chatをさらに便利にする3つの機能 -
TECH
Prometheusで辞書形式のメトリクスを持つExporterを作りたい! -
TECH
GTM経由でカスタムディメンションを取得するTypeScript -
TECH
Grafana Tempo×OpenTelemetryの導入方法 -
TECH
Grafana TempoとLokiの連携で進化するログ解析とトレーシング -
TECH
「Microsoft 365開発者プログラム」のアクティベーション方法 -
TECH
サインインなしでも使える! 開発者向けAI検索エンジン「Phind」をご紹介 -
TECH
え、高級言語しか触ったことないのにCPUを自作するんですか!? -
TECH
Github Copilotで、コミットメッセージもAIに考えてもらう方法 -
TECH
Terraform 1.5から追加されたimportブロックがすごい!! - この連載の一覧へ