AIコーディング時代の到来
AIを使ったコーディングが話題になっていますね。私も個人のプロジェクトやデモで実験的に使っていますが、ちょっとしたアプリやツールなら、それこそ人間には不可能な速度で爆速で開発することができるようになり、その体験に驚き興奮しています。一方で「そんなに便利に思えない」とか「Cline(Roo Code)、Cursor、Windsurf、GitHub Copilot等たくさんAIによるコーディングサポートツールが出てきていて、どれを使えばよいのか分からない」という理由で、なかなか利用に踏み出せない人も多いのではないでしょうか？
私が、ツールをいくつか試してみて感じたのは、それぞれのツールごとの使い勝手の違い、メリット・デメリットはありますが、開発の方向性としては共通していることです。それは、多くのツールがAIがCopilot（副操縦士）からPilot（操縦士）として振る舞うようになっていき、人間がコーディングするのでなく、人間がAIのコーディングのサポート・チェックをするという関係性になっていくことです。それによる良い、悪いは様々な議論があると思いますが、人間が楽な方、効率的な方向に流れていく過去の歴史からも、AIの進化のスピードからも、長期的に見てこの傾向は加速していき、電卓やエクセルを使って計算するのが当たり前になったように、AIでコーディングすることも徐々に常識化していくのではないかと感じています。
この記事では、上記のような方向性を踏まえた上でのAIコーディングの環境構築方法を紹介します。本記事では、主なターゲットとしてmacOSのローカル環境でVS CodeエディタとVS Codeエディタの拡張機能であるRoo Code（ClineというOSSの派生版。より高機能）を使用することを想定していますが、他のOS、リモート環境・Docker環境、他のAI開発ツール（Cursor, Copilot）でも、共通して約に立つ手法を紹介していきます。AIコーディングに興味ある人は、是非記事を読んで試してみてください。
AIコーディングツールの選定に関して
AIコーディングツールは、慣れているVS Codeエディタから乗り換えたくなかったため、拡張機能として使えるClineから派生した高機能なRoo Codeを利用しています。基本は同じなので、以降は基本Roo CodeもClineと記載します。
以下に、ツールごとの簡単な比較表を参考として載せておきます（表はDeep Researchを活用して作成しました）。
| ツール | 特徴 | メリット | デメリット | コスト |
|---|---|---|---|---|
| Cline | VS Codeエディタ拡張の自律型AIアシスト。複数ファイルにわたるコード修正やビルド、テストなどを自動化 | - オープンソースで無料 - 複数のLLM（GPTなど）に対応可 - 自由度の高い拡張性 |
- AIモデルの使用料は別途必要 - UIがシンプルで学習コストあり - 自動処理に手動承認が多い |
本体は無料（OSS）。LLMのAPI利用料はユーザー負担 |
| Cursor | VS Codeエディタの操作感を継承した独立型AIエディタ。チャット機能で複数ファイルを一括編集可能 | - コード生成の精度が高く、多機能 - VS Code由来のUIで移行が容易 - チャットを介した柔軟な操作 |
- 機能が豊富で学習コスト高め - 無料枠に制限あり - 大規模変更で都度確認が必要 |
無料プランあり。Pro版は月額20ドル |
| Windsurf | VS CodeエディタをフォークしたAI統合IDE。Codeiumエンジンを統合し、複数ファイルやターミナル操作も可 | - 個人利用は基本無料 - Cascadeモードで自動修正が容易 - 日本語にも対応 |
- 対応モデルが限定 - 一部VS Code拡張が動かない可能性 - オフライン利用不可 |
無料プランあり。Pro版月15ドル、Ultimate版月60ドル |
| GitHub Copilot | GitHub公式のAI補完ツール。クラウド経由でコードをリアルタイム提案 | - 導入が簡単で幅広い言語対応 - 学習コストが低い - 継続的なアップデート |
- 無料プランあるものの制限が厳しい - 大規模リファクタは苦手 - クラウド依存 |
個人は月額10ドル。ビジネス向けは月19ドル |
上から順に、AIの自律性が高いツールとなっています（CursorとWindsurfはほぼ同等）。
特に制約がなければ、自律性の高いClineで本記事の環境設定をすると、快適な開発体験が得られるのでおすすめです。ただ、他のツールでも設定を工夫したり、少し手動操作を我慢すれば同様の体験が得られると思います。なので、まずは1つのツールを使って開発を効率化すると共に、使いこなしのために何が重要かの勘所を掴んでその下準備を積み上げることを重視するのがよいと思います。本記事の内容も、多くはその下準備にフォーカスしていますので、多くのツールで応用のききやすい内容になっています。
事前設定
VS CodeエディタとClineの他、Clineの能力を最大限引き出すためのセットアップに関して説明します。全て設定することを推奨しますが、まずは試してみたいという方は、最低限最初の2つの以下だけ設定して次の使い方に進んでもらえればOKです。
- VS Codeエディタのセットアップ
- Cline（Roo Code）の設定
VS Codeエディタのセットアップ
VS Codeエディタのインストールをしましょう。
VS Codeディタのダウンロードサイトからダウンロードして、インストールした後、拡張機能として「Roo Code」を検索してインストールすればOKです。
より詳しくVS Codeエディタのインストール方法、基本的な使い方に関しては、拙作ですが以下Zennの書籍を参考にしてください。
Cline（Roo Code）の設定
LLM設定
ClineはOpenAI, Anthropicをはじめとして、複数のLLMのAPIに対応しています。Ollamaにも対応しているので、ローカルPCで動かしたLLMを使うことも可能です。
既に使っているものがあれば、それでもよいのですが、コーディングのコストパフォーマンスが高く、Clineとの相性が良いAnthropicのClaude 3.7 Sonnetを使うのがオススメです。
LLMの設定は、Clineの設定画面で、以下のようにAnthropicのAPI Keyを設定したうえで、モデルとしてAnthropicのclaude-3-7-sonnet-20250219を選択します。
もし、どうしても無料で使いたい場合はGoogleのGeminiのAPI KeyはGoogle AI Studioで取得できます（使用制限あり）ので、まずはそちらで試してみてもよいかと思います。
自動承認設定
自動承認（Auto-Approve）設定は、read-onlyのみをオンにしています。write operationをオンにすると、自動でどんどんファイルを書き換えてしまうので、慣れるまではオフにしておいた方がよいと思います。
Linter/Formatterの設定
細かいことですが、VS CodeエディタでLinter/Formatterの設定をしておくのがオススメです。
本記事では、主にPythonをメインで使用ソフトウェアを対象としてるため、Ruffを使っています。以下記事を参考にファイルをセーブしたら自動でLintチェック、Formatチェックフォーマットかけるように設定するのがオススメです。
AIのコーディング、意外に無駄な空白があったり、コーディングした後、AIが自分でLint/Formatのチェックをしたりするのですが、AIの無駄遣いなので専用のツールに任せたほうがよいです。これは人間がコーディングするときと同じですね。CI/CDに関しては、後ほど紹介するテンプレートに含まれているので、ここではエディタの設定だけでOKです。
Python以外のプロジェクトの場合は、適宜適切なLinter/Formatterを使いましょう。
GitHub CLI（ghコマンド）のセットアップ
GitHubにCLIでアクセスしたり、操作できるようにghコマンドをインストールします。ghコマンドを準備すると、AIがgitコマンドと組み合わせて、GitHubでのソフト開発に必要な一通りの操作ができるようになります。例えば、gitのコミットはもちろん、Pull RequestやコードレビューまでAIにやらせることができます。
ghは以下コマンドでインストールできます。
$ brew install gh
続いて、以下コマンド実行すると、GitHubの認証を行えます。
$ gh auth login
認証が完了すると、ghコマンドでGitHubの様々な操作を行うことができるようになります。
以下記事が、画面付きで分かりやすいので参考にしてください。
テンプレートリポジトリ
開発をしやすくするための型となるテンプレートリポジトリがあると良いです。
以下、参考に自分が個人開発用に用意したPython用のテンプレートリポジトリです。
以下の右側にある「Use this template」というボタンをクリックすると、自分のリポジトリにテンプレートをコピーして使用することができます。
このテンプレートには、以下の設定がされています。
-
.clinerules（後述） - RuffによるLint/FormatのCI/CD（参考）
- GitHubのPull Requestのテンプレート
他、Dockerfileやpytestの設定などもありますが、不要だったら必要なもの以外は削除したり、一部分だけ使っても大丈夫です。よく分からなければ、この後の.clinerulesで必要な箇所だけコピペすれば良いでしょう。
.clinerulesの設定
開発するリポジトリのトップに.clinerulesというファイルを作って、プロンプトを書いておくと、プロジェクトのカスタムインストラクションのように働きます。挙動から.clinerulesは、ファイルを変更すると動的に反映されるようです。
もしClineの挙動に.clinerulesが反映されてないと感じたときは、.clinerulesをエディタで開いたり、以下のプロンプトで一度確認してもらうのが確実です。
.clinerulesを確認してください
私が使っている.clinerulesは以下の通りです。上記テンプレートにも同じ内容のものが含まれています。
# Cline Rules
## ロール定義
あなたは熟練のPythonプログラマとしてコードを書いてください。
## 期待する回答
- 実装コードは省略せず、完全な形で提供
- 日本語での詳細な説明
## 注意事項
### 設計書
- 新規開発時は docs ディレクトリ以下に以下の内容を含む設計書 `design.md`を作成してください：
- 要件定義書
- 設計書（概略・機能・クラス構成）
- 既存のソフトウェアを修正する場合：
- 既存の設計書を参照してソフトウェアを開発してください
- 修正内容に応じて設計書も更新してください
- 設計書を作成したら、コードを作成する前にユーザーに設計書のチェックを依頼してください
### コーディング規約
- PEP8に従ったコードを書いてください
- ruffのフォーマッタでファイルの保存と同時に自動整形するので、フォーマットの修正は不要です
- GoogleスタイルのDocstringを書いてください
### テストコード
- テストコードを tests ディレクトリ以下に src ディレクトリと同じ構成で作成してください
- テストコードを作成したら pytest を実行してエラー無いことを確認してください。エラーが出たら修正してください
### Git操作
- gitの操作はgit statusでステータス確認しながら慎重に行ってください
- git管理されているファイルは、git mv や git rm を使って移動削除してください
### Pull Request(PR)
#### PR作成時
- PRを要望されたら、gitコマンドで差分を確認したうえで、`gh pr` コマンドを使ってPRを作成してください
- PRのdescriptionは .github/pull_request_template.md を読み取ってフォーマットを合わせてください
#### PRレビュー時
以下の手順でファイルごとにコメントを付けてください：
1. チェックする観点は .github/pull_request_template.md を参照してください
2. PRの差分を確認:
```bash
gh pr diff <PR番号>
```
3. ファイルごとに、変更後のファイル全体とPRの差分を確認した上でレビューコメントを追加:
```bash
gh api repos/<owner>/<repo>/pulls/<PR番号>/comments \
-F body="レビューコメント" \
-F commit_id="$(gh pr view <PR番号> --json headRefOid --jq .headRefOid)" \
-F path="対象ファイルのパス" \
-F position=<diffの行番号>
```
パラメータの説明：
- position: diffの行番号（新規ファイルの場合は1から開始）
- commit_id: PRの最新のコミットIDを自動取得
このようなプロンプトを設定することで、AIコーディングをより便利にできます。プロンプトがどう働くかは、この後の使い方で解説をしていきます。
VS Codeエディタ + Cline（Roo Code）を使ってみる
ここからは、実際にVS CodeエディタとClineを使ってAIコーディングをしていきましょう。
Clineの使い方は、拡張機能をインストールすると、左にロケットのアイコンが出てくるので、そちらをクリックすると、以下のような画面になるので、下のテキストボックスにClineへの指示（プロンプト）を入れていきます。
プロンプトをいれると、Clineが指示通りファイルを編集したり、コマンドを実行してくれたりするので、その結果をもとにまたプロンプトを入力するという流れです。
また、Clineはエディタで開いているファイルの内容をチェックするようなので、修正したいファイルやAIに注目して欲しいファイルがある場合は、あらかじめ開いておくと良いです。
また開いてないファイルやフォルダでもプロンプトで@xxxと@を使って指定することができます。特定のファイルの修正を指示したり、AIに参考情報として読んで欲しいときに使用しましょう。
Clineに限らず、多くのAIコーディングツールで同じように@でファイルやフォルダの指定ができます。
AIによるコーディング
続けて、AIでコーディングしていきます。ちょっとしたアプリやツールなら、素直にプロンプトで依頼すればOKです。
今回は、簡単なチャットアプリを作ってみたいと思います。ただ、簡易化するために、相手の返信にはLLMなど使わず、相槌をうつ形（ELIZA方式）とします。
プロンプトの例は以下です。もし使用したいライブラリや要件ががイメージできている場合は、ここに書いておきましょう。
チャットアプリを作ってください。要件は以下です。
- GUIはGradioを使ってつくってください。
- 相手の返信は、こちらの返信に対して、適当に何パータンか相槌をうつ形でOKです。
.clinerulesに以下のように書いているので、いきなりコーディングしないで、最初に設計書を作ってくれます（特に指示しないと、いきなり凄い勢いでコードを書きます）。
### 設計書
- 新規開発時は docs ディレクトリ以下に以下の内容を含む設計書を作成してください：
- 要件定義書 requirements.md
- 設計書（概略・機能・クラス構成） design.md
- 既存のソフトウェアを修正する場合：
- 既存の設計書を参照してソフトウェアを開発してください
- 修正内容に応じて設計書も更新してください
- 設計書を作成したら、コードを作成する前にユーザーに設計書のチェックを依頼してください
今回は簡単な例なので、特に設計書はいらないのですが、大きい規模になると自然言語（日本語）で設計書を書いておくと、後で内容を把握しやすいです。
新たにAIに指示するときも、AIに設計書を読ませてから作業をさせると、効率が良いことが多いです（人間と同じですね）。
コードを変更しているうちに仕様が変わったら、ドキュメントのアップデートも以下のようなプロンプトでAIにお願いすることもできます。
今までの変更を @/docs/ やREADME.mdに必要に応じて反映してください
ドキュメントのアップデートは手間なので、コードとドキュメントの乖離が起こるというのはソフト開発のあるあるですが、AIだとこのように一言お願いするだけで、手軽にアップデートできるのが良い点ですね。
LintチェックとFormatはAIにはやらせない
LintチェックとFormatはAIにやらせないようにしましょう。
この記事の事前設定のところでも説明しましたが、AIは結構無駄な空白などを入れます。また、自分でLint/Formatの修正をしようとしますが、決まった作業をAIにやらせるのは無駄なので自動化しましょう（このあたりは人間と同じですね）。
ruffで自動でFormatする場合は、ClineがFormatしないように、以下プロンプトで指示します（.clinerulesに書いておくのがよいでしょう）。
- ruffのフォーマッタでファイルの保存と同時に自動整形するので、フォーマットの修正は不要です
人による作業・修正
たまにAIの動きがじれったくなり、手をだしたくなるときもありますが、勝手に修正するとAIが混乱するので、なるべく人間は手を出さないのが効率が良かったりします。また変更点を把握しておくと、この後でGitでコミットやPull Requestするときに適切な内容を記述してもらうことができます。なので、簡単な修正でも、なるべくプロンプトでお願いしてAIに作業してもらうようにしましょう。
自分で修正した場合は、修正したことを以下のようなプロンプトでAIに教えてあげましょう。
@xxx のファイルを変更したので変更内容を確認してください。
AIと共同作業をしている気持ちになって、情報共有するのが大事です。任せれるところはどんどん任せてしまいましょう。
AIによるテスト
.clinerulesに以下のように記載しているので、勝手にテストコードも書いて、pytestでテストもしてくれます。
### テストコード
- テストコードを tests ディレクトリ以下に src ディレクトリと同じ構成で作成してください
- テストコードを作成したら pytest を実行してエラー無いことを確認してください。エラーが出たら修正してください
テストコードに関しては、なかなか手が回らないこともあるのでAIが書いてくれるのは嬉しいですが、必要なテストが書けているかは自分でチェックする必要があります。
このあたりは、漏れなくテストケースを抽出するために、色々工夫が必要と思いますが、本記事の対象外とします（まだ私も試行錯誤中です）。
AIによる動作確認
ウェブアプリの場合は、なんとClineが自分でブラウザにアクセスしてGUIを操作して動作確認をしてくれます。勝手に確認してくれるときもありますが、以下の通りプロンプトを実行すると、自分で確認しに行ってくれます（ブラウザでのアクセスは人間が承認する必要があります）。
ブラウザで動作を確認してください
AIがブラウザを操作して、動作チェックする様子は、結構未来感を感じます。
なお、ブラウザでの動作確認ができるかは、使用するLLMモデルにより異なります（Claude 3.7 Sonnetでは可能です）。
AIでPull Request作成
開発が一通り完了したら、Pull Request(PR)をしましょう。これもClineにおねがいできますが、あらかじめ事前設定で説明したghのインストールと設定しておく必要があります。
PRするために、ブランチを切ってファイルをコミットしましょう。以下のように指示します。
ブランチ切って、ファイルをコミットしてください。
以下のようにコマンドを提案してくれるので「Run Command」を実行します。
続いて以下のようにPR作成指示します。
PRを作成してください
すると、以下のようにPRをghコマンドを使って作成してくれます。
gh pr create --title "相槌チャットボットの実装" --body "# Pull Request
## 変更内容
Gradioを使用した相槌チャットボットの実装
### 追加した機能
- Gradioベースのチャットインターフェース
- ランダムな相槌パターンによる応答機能
- 日本語UIのサポート
- サンプルメッセージ機能
（中略）
## 動作確認
- [x] ユニットテストの追加・更新: 完了
- [x] 動作確認の実施: 完了
- [x] ドキュメントの更新: 完了
## チェックリスト
- [x] コーディング規約に準拠している
- [x] 適切なコメントを追加している
- [x] 必要なテストを追加している
- [x] ドキュメントを更新している"
ここで、PRでチェックリストまで作ってくれるのは、.clinerulesにあらかじめ以下のようにPRのテンプレートを読むように指示しているからです。
- PRのdescriptionは .github/pull_request_template.md を読み取ってフォーマットを合わせてください
PRのテンプレートには、あらかじめチェックすべき項目をチェックリストとして入れています。PRのテンプレートにプロジェクトでのルールやチェック項目を書いたりすることあると思いますが、これを人間だけでなくAIにも読ませることでコードの品質を上げます。
AIでコードレビュー
AIでコードレビューをすることもできます。ただ、AIがレビューするから人のレビューが不要というわけではないことには注意してください。仕様と実装が整合性とれているか、テストされているか、その他確認事項がチェックできているかは、少なくとも今のところは人が確認する必要があるでしょう。AIのレビューは、どちらかというと、しっかりレビューしてくれるレビュワーが1人増えたと考えるべきでしょう。うっかりミスを防止したり、人とは違う観点でチェックしてくれる強い味方という位置づけで利用するのが良いと思います。
コードレビューに関してもghコマンドのセットアップが必要です。コードレビューの際のプロンプト例は以下です。
1番目のPRをレビューしてください
レビューコメントは、GitHub APIを用いてコメントをつけています。結構複雑なので、.clinerulesに具体的なコードを記載することで、レビューを実現しています。
#### PRレビュー時
以下の手順でファイルごとにコメントを付けてください：
1. チェックする観点は .github/pull_request_template.md を参照してください
2. PRの差分を確認:
```bash
gh pr diff <PR番号>
```
3. ファイルごとに、変更後のファイル全体とPRの差分を確認した上でレビューコメントを追加:
```bash
gh api repos/<owner>/<repo>/pulls/<PR番号>/comments \
-F body="レビューコメント" \
-F commit_id="$(gh pr view <PR番号> --json headRefOid --jq .headRefOid)" \
-F path="対象ファイルのパス" \
-F position=<diffの行番号>
```
パラメータの説明：
- position: diffの行番号（新規ファイルの場合は1から開始）
- commit_id: PRの最新のコミットIDを自動取得
レビューすると、以下のようにGitHubのブラウザ上にコメントが付きます。
レビューが終わってマージしたら最低限の開発の流れは完了です。
あとは、この一連のサイクル繰り返して機能を増やしたり、問題点を改善していくこととなります。
Tips
便利なTips等です。よい使い方があったら追記していきます。
ドキュメント（設計書）の作成と更新
AIによるコーディングのところにも記載しましたが、大きな規模のソフトウェアになると、ドキュメントがより重要になってくると感じました。ドキュメントの重要性は、AIが無くても同じですね。
ドキュメントに関しては、おまかせでもある程度のものを生成AIが書いてくれますが、フォーマットを決めて作成する方が安定するし良いと思います。
私は、生成AIとチャットを繰り返すと、決まったフォーマットで設計書を自動で作成してくれるソフトを作って使っています。
このソフトで生成したドキュメントを、先程のテンプレートのdocsフォルダに格納すれば、ソフトをスムーズに開発することができます。なお、このソフト自体もベースはClineを使って30分ほどで作成しました。
実際のプロジェクトだと、ドキュメントの作成・アップデートがなかなかされないのが課題だったりもしますが、生成AIは、コードだけでなくドキュメント作成・修正も手軽にしてくれるのが良い点ですね。
Devcontainer内でClineの使用
Clineは、ターミナルでコマンドを実行できるので、場合によってはrm -rfのようなファイル削除のコマンドを実行することもあります。
デフォルトだと、コマンド実行前にユーザーに確認がありますが、自動承認の設定にしていたら、そのままファイルを消されてしまう可能性があります。そんな被害を防ぐために、Dockerのコンテナ内でClineを動かすことで安全にClineを動かすことができます。
VS CodeエディタではDevcontainerという拡張機能を使うことで、開発環境をDockerコンテナとして構築・管理することができて便利です。DevContainerについては、ZennのVS Code本の以下記事を参考にしてください。
本記事で紹介したテンプレートにもDevcontainerの設定ファイルが含まれているので、VS Codeエディタを起動した後、F1キーでコマンドパレットを開いてDev Containers: Open Folder in Container...を選択してテンプレートフォルダを選択すれば、Devcontainer内でClineが使用できます。
サンプルコードを参照させる
参考になるサンプルコードがあるなら、プロンプトで @ でファイルやURLを指定して読み込ませるのがよいです。サンプルコードがあると助かるのは人間もAIも同じですね。
特にAIが学習していない最新バージョンのAPIを使ったコードは、公式サイトの情報を参照させたり、過去に自分が作成したコードがあれば、それを参考にさせるとよいです。LLM関係のAPIだと、バージョンアップが激しいので、参考にするコードがないと古いモデルやAPIを使いがちなので気をつけましょう（理屈は分かりますが、LLMなんだからLLMのAPIは得意であってよ…とは思ってしまいます）。
Cline（Roo Code）でのターミナルの出力確認
Clineの魅力に、Cline自身がターミナルで実行したコマンドの出力を確認して、動作確認やエラー対応を自分でできることが挙げられます。ただ、環境によってはうまくこの出力の確認ができないケースがあるようです。私の環境でのワークアラウンドを以下記事に記載しました。
上記ではシェルを変更していますが、前節で紹介したDevcontainer環境を使用することでも、Cline（Roo Code）でコマンド出力を確認することが可能です。
コーディング以外の使い方
Clineをコーディング以外のことに使う方法です。結構いろいろできます。以下記事参照ください。
まとめ
AIコーディングの環境構築と、実際にAIによるコーディングの流れを紹介しました。まだ私自身は個人のプロジェクトや、デモ用の使い捨てのソフトでトライアルをしているという段階ですが、実際の業務にも実戦投入していける可能性も感じつつあります。
また、AIが仕事をしやすいように開発環境を整えるのは、ロボットのルンバが掃除できるように人間が家を片付けるのに似ているなと感じました。こうやって整理してみると、AIコーディングに必要な下準備は、人間にも重要・有効なものが多いことに気づかされます。実際、私も自分の開発環境をあらためて整理でき、非効率な部分を見直すことができるという思わぬメリットも享受できました。あと、.clinerulesをアップデートして便利になっていくのは、AIを育てている感もありよいですね。
今回はPythonとGitHubを使用する前提の環境構築でしたが、他の言語、環境でも、同じ考えで環境を構築すれば、AIでのコーディングを大きく効率化できると思います。
気になるAPI料金は、Clineが使用料金を教えてくれるのですが、この記事を1通り実施して100円程度といったところでした。十分金額の価値はあると思いますが、大きなソフトをつくるほど、どんどん使用料金が積み重なっていくので、個人で使用するには（特に学生だと）、使い続けるのはお金が気になるかもしれませんね。Ollamaを使ってローカルLLMを動かす方法もありますが、話題の「DeepSeek-R1」で、比較的ローカルで手軽に動く14Bくらいで試してみても、まだまだ実用的とは言い難いというのが私の実感です。将来的には、ローカルLLMも実用的になっていきコストの問題も解消されていくことを期待していますが、現状のコストは、ClineをはじめとしたAIコーディングツール導入のネックの1つかもしれません。
松尾研究所では、こういったAIに必要なAPI料金は、必要であれば申請の上でかなり気軽に利用することができます（いつも関係者の素早い対応に感謝しています）。また、AIコーディングに関しても、Slackの専用チャンネル（#club_ai_coding)を立ち上げ、有志による勉強会でより効率的な使いこなしに関して熱い議論が行われています。既に、第一回の勉強会も開催され、大きな盛り上がりを見せました。初回で自分が登壇したのですが、参加者には私よりずっとAIコーディングツールを使いこなしている人もいて、私も大きな刺激を受けています。なお、このような松尾研究所の自発的な勉強会文化についてはこちらの記事も参考にしてください。
最後に、AIコーディング、AIによる開発効率化に興味ある方は、是非記事末尾の採用ページもチェックしてみてください！
参考記事
Cline / RooCodeを安全に使うためにDevContainerを使い始めた
Clineに全部賭ける前に 〜Clineの動作原理を深掘り〜
関連記事
変更履歴
- 2025/03/16 参考記事のリンク追加
- 2025/03/05 リンク追加
Discussion
GitHub Compilot Freeという形で一部機能制限ではありますが、無料版が去年出てます。
ありがとうございます。表修正しました。