AIの普及と使用方法
すっかりAIが開発に組み込まれて、AIがないと生きていけないエンジニアになってしまったなぁと思うんですけど、お二人はどうですか?
同じく。いや、ほんとそう。うん。そうだよね。ほんとそう。なんか、今回はそのAIを普段、ITトリオの3人がどう使っているかについてを話そうと思います。
なんか、ちょくちょくAIを絡めたキャリアについての話をしてきたんですけど、実際、AIをどう使っているかみたいな、よくありそうな話題は、実は1年ぐらい触れてないんですよ、ITトリオで。
たぶん。1年も喋ってないんだ、そういう話。そうなんですよ。で、最後に触れたのが、2024年の10月27日と、1年前。そう、1年前。エピソード120と、その1つ前の119で、そのあたりで、
その119回、2024年10月20日の回が、AIエディターカーソルの良さを教えてもらおうということで、
なんか、チーズがカーソルを使い始めたんで、ちょっと良さを教えてもらいましょう、みたいな感じで。で、チーズはAIというか、カーソルがないとデストコードも書けません。
で、僕は、まあなんか気持ちわかるけど、ベースコードのコパイロットでいいじゃん。何が違うの。なぶちゃんは、AIまだ使ったこともないから、いろいろ教えてくださいっていう状況が、1年前ぐらい。
はいはいはい。だったんですが、もうね、この1年で全然変わったなと思っていて。変わりすぎたね。そう、変わりすぎてる。
で、僕が今どう使っているかについてはじめに話すと、僕はもう引き続きカーソルを使ってますと。なんか、意図的にもうカーソル以外使わないようにしてますと。
意図的になんだ、そこ。
そうですね。それも、お言いを話せればなんですか。で、実際どこで使ってるかというと、基本的にはもう今は、カーソルのエージェントを使うことが多いですね。
1年前とかだとタブで保管してが便利だとか言ってた気がするんですけど、今はもうタブを逆に多分使う機会が少なくなって、AIに指示を出して書いてもらって、それを自分でレビューしていろいろ改善していくっていうのが多分メインになってます。
で、エディターのカーソルをよく使うんですけど、最近はそのカーソルのバックグラウンドエージェントとかがいろんなところと連携してるので、仕事ではLINEARっていうタスク管理ツール使ってるんですけど、そこだと。
LINEAR。
LINEARってやつ?
LINEAR。
ちょっと日本語だと何て呼ばれてるかわかんないですけど、LINEARってやつ。
最近流行りというか、スタートアップが開発しているタスク管理ツールみたいなやつですね。
そことカーソルはもう連携してるんで、そこのチケットを作ってチケットでカーソルをメンションすると、カーソルのバックグラウンドエージェントが起動して、カーソル側の環境でコードを書いて、指示を出せばそこからアプリリクエストも作ってくれるみたいな。
はいはいはいはい。
っていうのもめちゃくちゃ非常によく使っている。
はいはいはい。
レビューについても、会社だとコードラビットとかいうレビュー系のツールを使っているので、それが勝手に走っているようになっているし、
自分で個人開発するときはカーソルと連携してるんで、自分の個人アカウントを。
それでプリリクエストにカーソルのメンションをしてちょっとレビューしてもらったりとかもするし、
あとはそうですね、カーソルは自分の個人でもサブスクライブしてるんで、
個人の場合はGitHubのレポジトリと紐付けてあるので、そこで一周を作って、その一周の中でカーソルをメンションしてこれやれって実装してもらう。
必要があればカーソルにプルしてきて、プルしてきて自分で動作確認をしてプリリクエストをマージするっていう感じでやってますね。
だからエージェントをもうバリバリ使っていて、そのエージェントを呼び出すのはエディターからもやるし、
どっかのタスク管理ツールからもやるしという感じで、必要があればプルするという感じでやってますね。
なんか最近ITトリオのウェブサイトをいろいろアップデートしたんですけど、何をアップデートしたっけな。
エピソードの検索機能をつけたりとか、エピソードの文字起こし機能をつけたりとかしたんですけど、
それもGitHubの一周を立ててカーソルにメンションして全部ほぼ98%ぐらいやってもらったっていう感じで。
なかなかもう、自分でコードを書くことも全然あるんですけど、結構少なくなってきたなと。
あとMCPとかをつなげばいろいろできるんで、バグの調査とかもセンチュリーをカーソルとつなげているんで、
そこでチケットというかバグのURLを、センチュリーのバグのURLをメンションした上で、
これについて分析して解決しろって指示を出してやって、自分はレビューをして動作確認をしてとかやってますね。
という、主にカーソルでエージェントを使ってますよっていう感じです。
チズの開発スタイル
では次に、ちずさん、あなたは普段どういう風に絵を使っているかプレゼンよろしくお願いします。
はい、まずカーソルはあんまり使わなくなりました。
クロードコードっていうのをベースで使っています。
まず、Task ManagerはJiraを使っているから、Jira MCP使ってクロードコード側でアクセスできるようにしています。
最近ちょっと仕様駆動開発っていうのをよく聞くと思うんですけど、
AWSが元々ベースになっているのかな。
仕様駆動開発的なものを今取り入れようとしている段階で、
要件定義をまずするところは、Jiraというタスク管理ツールを使っているから、
クロードコードでJira MCPを叩いて要件定義を作る。
あとはデザインであったりとか、実装のタスクとかも作ってもらっていて、
それがクロードコードだと、要件定義が得意なサブエージェントとか、
技術設計が得意なサブエージェントとかを作って、コマンドを実行して、
それをオートでやってくれるみたいなのができるんですよ。
なるほど。
それで、要件定義から実装計画までをまずやってもらって、
まずそこをレビューするところから始まっているかな。
あと、開発はそれを実行してもらって、レビューしてっていうのを繰り返して、
コードレビューはクロードコードがレビューしてくれる機能もあるから、
プルリク作ったらクロードコードがレビューしてくれて、
私も目視でレビューしてみたいな感じで、
仕事の7割ぐらいがAIのおかげで、実装じゃなくてレビューになってるなっていう感覚があるかな。
あとちょっとなんか、自分の中で気になっている話題的に言うと、
クロードコードは持てるコンテキストに上限があるので、
ちゃんと自分のプロジェクトのガイドラインをちゃんと書いて、
コンテキスト残すとか、
この要件のドキュメントを生成してもらうんだけど、
この記録プロセス的なものでは。
それで、たとえクロードコードが保持できるコンテキスト量がマックスになって、
オートコンパクトっていうコンテキストをちょっと削るようなことを自動でクロードコードはやるんだけど、
それをしてても精度が高く保ってあるように工夫するようなコンテキストエンジニアリング的なものをちょっと取り入れて使っていたりするかな。
なるほど。
使いこなしてますね。
めっちゃ使いこなしてるね。
なんか当時よりちゃんとやってるかもしれない、そういう意味で言うと。
当時だってエージェントもあんまりなかった。
当時の放送聞いても、その時ちょうどカーソルのコンポーザーが出始めたよ。
はいはいはい。
懐かしい、なんかもはや。
そういう話をしてたぐらいなんで。
ただただひたすらタブタブタブしてた時だね。
全然違うよね。
うんうんうん。
ナベのAI利用
1年前にAを使っていなかったなべちゃんは、じゃあ現在どうなのかっていうのが気になるところなんですけど、どうですか?
そうだね、なんかみんなすごいね。
俺そこまで使いこなしてる自信ないわ。
最近はもうさ、チャットGPTのGPT5か、でずっとやってるんだけど、
でそれと連携して、コーデックスか、コーデックスがエージェントあると思うんだけど。
でも今結構メジャーだし精度いいって言うよね。
前までGPT4の時かな、コード出してもらった時はめちゃくちゃ直すとこいっぱいあって、
これもあれも直すっていうのがあった。
大枠作れば良かったけど、やっぱり実際使ってないと結構時間かかってたんだけど、
今さ、めちゃくちゃ最初から精度高いコード出してくれるからめっちゃ楽やんと思って。
ちょっとレビューして、
ほんとにすぐコードそのままパッて書けるから、
これマジプロタイピングもすぐできるし、めちゃくちゃいいなと思って。
で、しかもコーデックスだとGitHubと連携してくれるから、
コードレビューとかも全部自動でやってくれるし、
プリリックとかも勝手に作ってくれるから、こうやってって言ったら。
そこら辺もあるから、ほんともうコーデックスで全部GitHubで色々プリリックとかレビューとか全部投げてもらって、
開発してって感じでやってるって感じで。
だからそんな複雑なことじゃないかも。
ほんとにもうずっとそこでプロンプト打って、
良さそう、OKって言ってやってるだけだから。
コーデックスCLIっすよね。
コーデックスCLI、そうそうそう。
で、そのターミナル開いて、そこで単純に指示を出して、
これやってください、あれやってくださいっていうのを繰り返してるって感じ。
今でもVS Codeとかにはあるよね。
なんか拡張機能とかもあるよね、確か。
そうね、VS Codeにもね。
私コーデックス使ってないんだけど。
あると思う、あると思う。
VS Codeでもできると思う。
だから別に特別なことやってないんだよね、ほんとに。
なるほどね。
じゃあ1年前と変わらず一歩遅れていると。
一歩遅れてるかもね。
一歩遅れてるけど、でも困ってはないね、正直。
でもなんかさ、私は多分なべちゃんと状況が違くて、
大型プロジェクトをチームの、大規模チームで開発しているから、
やっていることとかもたくさんあるかなって思ってて。
それはあるね。
そう、なべちゃんは個人だから、
なんかここまでやるのは過剰かなって思ってて。
私がさっき説明したくらいな。
要件もさ、たぶんなべちゃん自身が考えるものじゃん。
そうそうそうそう。
要件はすでに定義された要件仕様書的なものを連携しているところがベースになって、
そこからエンジニアから見て、ここもうちょっと詰めた方がいいよねとかはあるけど、
なんかベースなんだろう、チームでやっているから、
ちょっと状況が違うっていうのもあるかもしれない。
それはあると思う。
個人で、僕も個人開発で最近、
AIを活用した開発の流れ
新しくアプリ作るかと思ってデスクトップアプリなんですけど、
作っていたんですが、それ作るときは単純にカーソルのエージェントにどんどんお願いして、
どうたらこうたらっていうのを繰り返していた感じ。
ただ一つ違うなと思ったのは、
GitHubとかJiraでもLinearでも何でもいいんですけど、
そこから指示出せるってなると、
なんか隙間時間の活用はすごい楽になったなという感じがあり、
僕その通勤時間30分くらいあるんですけど、朝と夜それぞれ片道で、
30分弱かな。
その間に個人開発の指示をGitHubの一周上で書いて、
カーソルメンションしてこれやっといてって、
ベース乗るときのお願いして、
帰ってきたら開いて、ちょっとレビューするとかをやっていると、
なんかちょっと単純にCLIとかエディターを開くだけ以上のことが、
ちょっとなんか時間活用できるなという感じはあり、
なんか忙しいときにそれはできるかも。
Linearは通勤時間も活用してて。
いやでもそれ結局できるのは楽だからっていう感じがあるんですね。
活動、活用してるとは言いつつ、
別に指示出し数分で終わるし、
数分で使って指示出した後は別に、
YouTubeを見ようが、Podcastを聞こうが、
Xを見ようが勝手に物事進んでるんで、
なんか楽なんですね。
楽だからできてる感じがある。
確かに。
なんか一回、VZeroって時流行ったじゃんね。
バーセルが作ってた、その7時でNext.jsとかで。
あったね。
前の放送でも、チーズめちゃくちゃ絶賛してました。
そうそうそう。
個人で適当なアプリ作るなら、
これを使ってたなっていうことを思い出して。
個人でやるのと大勢でやるのは違うよね。
なんか僕がその、
全然違うと思う。
タスクツールの中で指示出すのが好きな、
違う理由の一つに、
上手くいくプロンプトとか指示の出し方があったら、
そのチケットをチームで共有して、
これ良かったですよっていうことで、
チケットの共有がすごい簡単にできるっていうのもあって。
はいはいはい。
エディタでやってたら、
共有もできないことはないけど、
ちょっとワンステップあるじゃないですか。
チケットだとそのまんまできるし、
なんならチケットの書き方によっては、
前回のプロンプトを参考にして、
チケットを書いて、
子どものタスクを分けて、
引き継いでやるとかもできるんで、
そこは確かに働き方というか、
チームの大きさとか色々よるなという感じがしてましたね。
ツールの比較と進化
クロードコードだったら、
コマンドとかでそのプロンプトを共通化できるから、
例えばプルリク作るにしても、
タイトルのルールであったりとか、
サマリーの書き方のルールであったりとかを統一できるとか、
こういうルールで書いてくださいねって書けるから。
エージェント用のマークダウンファイルを、
ドキュメントとして用意するみたいなのも。
クロードコードでもそうですし、
カーソルでも、他のエージェント系でも最近はよく聞きますよね。
エージェントドットMDとか。
エージェントドットMDでカーソルも使えるようになったからね。
クロードは使いません。
エージェントドットMD確か。
クロードだけ使えなくてちょっと文句言ってると見かけたら、
そうなんだ。
反してるから、世界って。
ITと利用。
僕は最初に言ったけど、
カーソル以外は今ほぼ触ってなくてですね。
意図的にそうしてるんですけど、
それはAIづかりをしたくないからそうしてるっていうのがあって。
多いからね。
カーソルってだいたいいつも不動の1位か2位か3位ぐらいには絶対いるんですよね。
1位か2位にいるんですよね。
クロードコードが登場したときって、
結構カーソルよりクロードコードだってなったんですけど、
1、2ヶ月すると、
カーソルにもCLI機能が出て、
タイミングよりだけで使えるようになったよっていうのもあったし、
ちょっと1ヶ月クロードコードを使った人が、
やっぱりカーソルのほうがいいって戻ってくることもあったりして、
だからツール自体に、
それとキロもそうか、
キロの仕様駆動開発みたいなのも、
クロードコードもそもそも、
仕様を出した後にプランモードで仕様を組み立てて実行するっていうモードがあったらしいですね。
なるほど、それは便利そうだと思ってたんですけど、
カーソルはそれ最初なかったんですが、
カーソルも1、2ヶ月したらそのプランモード実装されてましたんで、
なので僕としては、
カーソル使っていれば1、2ヶ月ちょっと遅れることはあっても、
その機能来るんだなと思って、
僕的にはいろんなAIの最新を追ってると、
気持ち疲れちゃいそうだなみたいな。
そうね。
例えるなら、
ウェブのフロントエンドがいろいろ立ち上がってきた中で、
リアクトとアンギュラーとビューを全部最新を追って、
最新でこっちの方がいいってなる度に切り替えると、
なんとなく感覚に出るのかなと思って、
それをするよりかは、
ある程度いいポジションにいる中の1つを取って、
それを自分の中で清めていくというか、
使い方をしておけば別に。
マジその感覚に近いかも。
ツールよりプロセスが大事かなって思ってたりするかな。
結果ツールの機能だったら、
後々追って追加されることが期待できると思うんですよ。
何ができるかじゃなくて、
どう使うかがめちゃくちゃ重要かなと思ってて、
そういうコンテキストをうまく扱えるように、
それこそエージェントMDとかは、
そのコンテキストを与えるためのドックファイルだと思うんだけど、
それが各ツールで共有で使えるのがエージェントMDじゃんね。
それってエージェントMDの書き方の方が重要じゃん。
エージェントMDというツールより。
どういうコンテキストを与えると、
より良いコードがアウトプットとして出せるか。
そういう仕様まで組み込んで、
AIに組み込んで作ってもらうかとか、
そういう使い方の方が重要だなっていうのは最近感じている。
たしかに。
キロっていうツールではあるけど、
あれは仕様駆動のためのツールだったけど、
そういうキロが考えたプロセスっていうものを別のツールで使うとか、
今それがスペックキットだっけな、GitHubの。
そうなんだ。
コマンドラインを生成できるツールとかもあったり、
仕様駆動をサポートしてくれるようなコマンドラインを、
新しい働き方の模索
クロードクラインとかいろんなツールに適応して、
仕様駆動ができるようにするツールとかもあったりするから、
どんなツール使ってるっていうのも、
たしかに制度の上で大事かもしれないけど、
それよりどうやって使うかのところにフォーカスを置いて学習していった方が、
AIにファンしてはいいなっていうふうには私は最近感じているかな。
個人だとさ、
普通に個人でやってるだけだと、
そういう情報入ってるからマジで助かるね。
やっぱり組織でやってるのいいね。
いろいろ入ってくるから情報が。
でもそういう情報、みんなようげい議論しとるじゃん。
すごいな。
ネット上でも。
クロードクライアントのアウトプットがカスになったとか。
いや、よくあるよね。
そうなんだよね。アウトプット悪いよね。
よかったよかった。一緒じゃん。気持ちいいって。
みんな期待してるもんね、すごく。
どっちが良くなった、どっちがどうだみたいなね。
そこはたしかにね、結構日が変われば変わってくるから。
そうそう。みんなアダコーダアダコーダ言ってる。
気にしてもしょうがない。
たしかに僕もどう使うかとか、自分の仕事の仕方をAI中心に変えていくみたいな心がけが必要だなと思って。
それはあるね。
今までの仕事の仕方をキープしながらAI使うだと、たしかにどうしても限界くるなみたいな。
結局AIに出しても待ってる間に何するのか問題とか、レビューが多くなる問題とか、
パラレルで指示出したらレビューするときに突っ返って指示出し直してると時間かかる問題とかいろいろあると思うんですけど。
それを自分が行動を書く、最終的に行動を書くという前提。
自分が全部最後に行動を書いて全部動作確認してっていう、もちろんそれも必要なときがあるんですけど。
とにかく今までの仕事のやり方を前提に、その途中にAIを組み込むみたいな考え方だと、
どうしてもAIを使ったツールというか、いろいろ出てくるツールを最優先というか最適化して使えないなという感じがあるので。
逆にそのAIを最適化して使うために日々の仕事のやり方をどう変えるかみたいな。
なんか僕はいろいろ試していて最適化は見つかってないんですけれども。
なんかAIの指示出した後の待ち時間があったりして、でも自分の手を動かさなきゃ解決できない問題もあるっていう場合は、
じゃあ朝に30分とか1時間の時間を確保して、その時間をAIに指示出す時間にして、
その後の待ち時間を自分の手を動かす作業にして、ご飯食べた後にレビューをたくさんやるみたいなフローにしようかなとか試してみたりとかいろいろしてるんですけど。
なんかそういう感じでAIを最適に使うための仕事の自分のスタイルを見つけないといけないなということを最近思っていて、
毎日それができてるわけじゃないんですけど。
だからなんか今までの思い込みじゃないですけど、今まで成功していたやり方を意図して捨てるというか、
意図して変えるみたいなことをやっていかないと、別に死にはしないんですけど、
別にトップパフォーマーを目指すっていうわけでもないんですけど、
なんかより良い生産性は生まれないなというか、限界が来るなというふうに思っていて、
そういう心分けを最近気をつけようと思っています。
どうしても今までの仕事のやり方に引きずられて、どうしても今までのやり方を勝手に自分の手が始めてしまう。
そうじゃなくて、
そうなんだ。
そうじゃない、そうじゃないっていうのを意図して変えていかないと、
若手エンジニアの学習方法
多分AIを前提にして育つ若手には負けちゃうというか、仕事を捉えるなという感じは。
ちょっと難しいなと思うのは、前提知識結構いると思ってるんだけどね、俺はまだ。
いるとは思う。だって結果レビューするのはこっちだし、彼の判断ができないからね、その学習は必要だと思う。
AIにいる人たちがさ、そこの学習を飛ばして逆になっているのかな、感覚で操作しそうとか、そういうの思うけどね、ちょっとどうなんだろう、わかんないけど。
でも、なんか主題は多分そのAIを活用するノウハウを若手が持っているっていう話だから、
本体の技術力を侮ってはいけないのは確かだとは思う。
私、学習の仕方もAを使うことによって全然変わってるなという気がする。
あー、確かにそれはそうだな。
これ若手の話じゃないんですけど、テックワールドっていうテック系のYouTuberいるのご存知ですか?
わかんない。
ちょっと前、かなとか北米に来てて話したりしていて、その北米に来ている中で、マイクロソフトの牛尾さんにインタビューしていた回がYouTubeに上がってたんですけど、
牛尾さんの最近のコードの学習の仕方を聞くと、AIにとにかく分かるまで無限に聞き続けるという学習方法をやっていて、
自分より上のレベルのエンジニアが作ったプロテクトを9%理解しなきゃいけない。
理解に時間をかけないとAIを使えないことが前提において、その理解のためにAIをめちゃくちゃ活用しまくるみたいな。
AIにそのプロテクトを読み込ませて、質問しまくって、関連知識でわからないことがあるが、それもさらに質問しまくってっていうのを数時間やると。
それやると、そのAIを使わなかった数時間の学習よりも、かなり学習スピードがアップして、いろいろ深いところまで分かるようになっていいですと言っていたんですよね。
なるほどね。
だから、確かに僕もそこまで学習のためにAIを使えていないと思うんですけど、
その新しく来るAI、シャジ化というか、AIがもうあるの普通ですよねっていう若手の人たちにとっては、僕たちが想像ができない学習の仕方とかもしてくると思うので。
でも、そこの物を作るっていう過程のプロセスだけじゃなくてね、きっと学習とか、何か知識を得るまでのプロセスにもAIが組み込まれてるって考えるとね。
ちょっとだけ疑問なのは、ハルシネイショとかやっぱあるから。
はいはいはい。そうね、それちょっと不安だよね。
そう、そこで本とかと組み合わせて、本の理解を深めるためにAIでなんとなく分かった気になって、
100%か90%みたいなところは、ちゃんとその文献とか参考にしていくみたいな方が多分いいのかなって気がするけどね。
なんかね、メインとなる文献があって、そこから自分が理解できなかったところサポートしてもらうくらいがちょうどいいのかもしれないね。
って思うけどどうなんだろうね。
まあ、それは分かんないですけど、何にせよ、その辺りはやる人はやると思うんで。
まあね。
頼りに今思ってます、人の道。
何て言うんでしょう、言い方合ってるか分かんないけど、どうせ頭いい人は絵を使った最適化を絶対生み出すはずなんで。
絵を使ってるからこれだけできないみたいなふうに思ってると、多分その頭いい若手にちょっとオーマイガーされてしまうので。
オーマイガー。
思うんだけど、多分AIできたところで頭いい人がさ、頭さらに良くなるだけで、
今まで勉強できなかった人がさらにできるようになるかっていうのはちょっと俺は疑問なんでね、そこは。
それは同意かもしれない。
結局学ぶ意思とかが能動的にある人じゃないと、それもAIも結局学ぶために使うというよりかは、楽をするために使うというだけで終わってしまって、
楽をして使ってると自分の血肉にならないみたいなのは多分ありそうだなと思ったりはしますね。
私若干それに対してね、自分自身不安抱えてるかもしれない。
自分自身がこの数年間で技術力が上がったかって言われるとちょっと怪しい。正直言うと。
そこは今後、技術の発展がどうなるか次第かなという気はしてて、
昔だったら16進数を直接書いてるのがプログラミングだったと思うんですけど、
もう今だったら別にそんなの、何、面影もないじゃないですか。
面影はあるけど。
面影はまだ触れることはないね。
16進数直接書いてた人たちが最初にC言語とかC++とか見た頃の時代は、
C言語とか使うなんてもうエンジニアとして終わってるではないですけど、
よく言われる。
新しい方向ではないみたいな。
それで技術力は身につかないみたいな雰囲気だったけど、別に今はそうではないから。
これから技術力の定義がどうなるかは知らないけれども、
その中にAIはどう使いこなせるかっていうのは確実に技術力の一つの指標には組み込まれるんだろうなという気がしてるんで。
今までのAIが登場する前の視点からすると確かに技術力は伸びてないのかもしれないが、
その技術力っていう視点自体も変わっていくから、
どのみちチーズは成長するんじゃない。
チーズは成長するね。
よくわかんなくなった。
ありがとう。結論ありがとう。
別方向での学習とかはやっぱりしてるわけだから。
そうね、直近AIをどう活用するかは結構勉強してたから、そういう意味の学習はしていたかもね。
学習自体を止めなければ大丈夫なんじゃないかなって気はしてますけど、逆に学習を止めてしまうとどのみちダメだなという感じがしております。
ありがとうございます。なんとなく理解しました。
今日はそんな感じかな。
また1年後にAIの使い方について話したら全然違うことを言ってると思いますので、楽しみにします。
世界違いそう。むしろ違いってあってほしい。
AIの未来
全然違うツールとかフローが作成されてて、もう世界がまた変わってる可能性が結構ある。
それを楽しみにしていきましょう。
ということで最後まで聞いてくださりありがとうございました。
ITトリオは各週月曜日に更新されます。
Spotify、Apple Podcast、YouTubeなどで番組フォローを是非よろしくお願いします。
レビュー、コメント、お便りも募集しています。
お便りフォームのリンクは放送の概要欄にあるので、どしどし送ってください。
またXSベースがあるととても嬉しいです。
ハッシュタグITトリオでお待ちしています。
それではまた次回お会いしましょう。
さようなら。
