LEGALブログ（リーガル社員のここだけの話）

（立会決済支援サービスご紹介セミナー ～スマホで完結！決済現場でオンライン申請～）

みなさんこんにちは。ブログ編集チームです。

今回は6月４日に開催予定の弊社オンラインセミナーについてのご案内をいたします。
本セミナーでは弊社“権” のオプションサービスとして新たにリリースした新サービス「立会決済支援サービス」のご紹介をいたします。

この「立会決済支援サービス」は決済現場でスマホやタブレットなどお持ちのデバイスを使って
・コンビニ証明書の真贋確認
・預かった登記識別情報をスマホのカメラで提供様式を作成
・押印済みの登記原因証明情報をスマホのカメラで添付情報として取り込み
を行いそのままオンライン申請、処理状況の確認までできるため、決済現場における司法書士の先生方の業務効率と取引の安全性を飛躍的に向上させる画期的なサービスです。

・オンライン申請を出先で行いたい方
・立会決済業務の効率化を考えている方
・不動産取引時の差し押さえリスク等を極限まで減らしたい方
はぜひご参加ください！

本セミナーではサービスの概要からデモンストレーション、実務での利用シナリオなども含めて詳しくご説明をいたします。

※5/15の日本経済新聞にも掲載されました！

今回もZoomウェビナーを利用した事前お申込み制でのWeb開催ですので、インターネットに接続されたPCやスマートフォン等をお持ちの方は無料でご参加いただけます。
また、誠に勝手ながら300名の定員に達し次第締め切りとさせていただきますので、ご参加を希望される方はお早めにお申し込みください。
詳細とお申込み方法につきましては、下記「Legalオンラインセミナーページ」よりご確認ください。

今回はちょっと都合がつかないという方も、今後様々なオンラインセミナーを開催する予定ですので、次回以降でのご参加をお待ちしております！

■開催日時：2025年６月４日（水）17:00～1時間程度
■開催方式：Zoomウェビナーによるオンラインセミナー
■参加費：無料
■定員：300名（先着順となります。定員になりましたら申込受付を終了させて
いただきます。予めご了承ください。）
■詳細・申込：【セミナーの詳細をみる】

こんにちは。イノベーション開発部の万場です。

日々ソースコードと向き合っていると、ふと「ソース」という言葉に親しみを覚える瞬間があります。
コードを書くうえでの「こだわり」は人それぞれですが、実は「ソース（調味料）」にも地域ごとに驚くほどのこだわりと違いがあることをご存じでしょうか。

私は関東出身ですが、リーガル本社がある四国に移住してから、ソース文化の違いに驚かされました。
たとえば、たこ焼きやお好み焼き。東日本では「中濃ソース」がオールラウンダーとして広く使われていますが、四国（西日本）では、料理に応じてさまざまな種類のソースを使い分けるのが当たり前のようです。

お好み焼きには甘みとコクのある専用ソース、たこ焼きにはスパイシーな専用ソース、さらに串カツにはまた別のソース、といった具合に細かく使い分けられています。
最初は「ソースはソースでしょ」と思っていた私も、地元の人たちと食事を重ねるうちに、その奥深さにすっかり惹かれていきました。

調べてみると、東日本と西日本ではソースの種類そのものが違う文化背景を持っているようです。
東日本では「中濃ソース」が標準的で、これはウスターソースの流れを汲みながら少しとろみを持たせた万能型。
一方、西日本では、用途に応じた専用ソース文化が根付いており、味の濃さや甘さ、スパイシーさなどがきめ細かく調整されています。

この違いは、まるでソースコードを書くときに、製品の統一感を重視して汎用的な部品を設計する場合と、
機能ごとに最適なライブラリやフレームワークを選び、製品特性に応じた独自設計を取り入れる場合に通じるものがあります。
どちらが良い・悪いというものではなく、それぞれの環境や文化に寄り添った工夫が、製品の完成度（＝味）を高めることにつながると、改めて感じました。

今後、ソースコードを書くときには、ときどき「ソース（調味料）」の世界にも思いを馳せながら、より良い製品づくりに生かしていきたいと思います。

　こんにちは。CSサポート部の井上です。
　前回のブログ記事で今年の10月14日にMicrosoft社のoffice2016と2019の延長サポートが終了する件についてお話ししました。今回は、その続きとして、現在ご利用されているパソコン（Windows11）にoffice2016もしくは2019がインストールされている場合にどのような手順で新しいofficeに入れ替えしたらいいのかについてお話ししたいと思います。

　まず、手順としては、大きく分けて2通りあります。まず1つ目として、既存のoffice製品がインストールされた状態で新しいofficeをインストールする方法。2つ目は、既存のoffice製品をアンインストールしてから新しいofficeをインストールする方法です。皆さんはどちらの方法を選択されますか？

　もし、1つ目の方法を選択された場合、新しいofficeをインストールする前に自動で古いofficeをアンインストールする処理が動きますが完全にアンインストールされず、作業後にofficeを利用するリーガル製品を含めたアプリが正常に動作しないケースがあります。このようなトラブルを起こさないためにも新しいofficeに入れ替えをご検討されている方は、必ず先に古いofficeをアンインストールしてから新しいofficeをインストールすることをおすすめします。Officeのアンインストール手順については、以下リンクをご参考ください。対象のofficeをご利用されている皆さん、もしご自身で作業される際にこの記事を思い出していただけると幸いです。

【Microsoft社の公式サイト　参考ページ】
■officeのアンインストール手順はこちら

こんにちは、イノベーション開発部の大西です。

最近の生成AIの進化は目覚ましく、単なるプログラムコード補完の域を超えて、プログラムの設計から実装、
テストまでを一気通貫でAIに任せるような使い方が注目を集めています。
昨年までは、エンジニアが自分でプログラムを設計して、GPTなどのAIを補助的に使うのが一般的でしたが、
今では「こういうアプリを作って」と指示するだけで、まるごと一式を自動生成してしまうサービスやツールも登場しています。

しかし今話題になっているこのようなサービスが、「果たしてどれほど実用に足るのか？」という素朴な疑問が湧いてきました。
実際に生成AIがどこまでのレベルでコードを書けるのか、自分の目で確かめてみる必要がある。
そんな思いから、今回“ある生成AIツール”を使って、ゼロからのアプリ開発を体験してみることにしました。

最近は、生成AIによるプログラミング支援ツールも多様化してきています。
たとえば、CursorのようにAI機能を組み込んだ専用エディタもあれば、既存のエディタに拡張機能としてAIを統合するタイプもあります。

今回はその中でも、普段から使い慣れているVisual Studio Codeに拡張機能として導入できる「Cline」というツールを試してみることにしました。
Clineは、コード生成用LLMとして定評のあるAnthropic社のClaude 3.5や3.7と高い親和性を持っており、
プロジェクト全体の構造を意識したコード生成や、一貫性のあるファイル出力が期待できるとされています。
導入も比較的シンプルで、APIキーを用意すればすぐに利用を開始できるので、とてもお手軽です。

今回は、チュートリアルサイトで紹介されていた例を参考に、コミック本を管理するWebアプリの作成に挑戦しました。
Clineへの指示は、以下のような箇条書きのプロンプトを日本語で入力しただけです：

・HTML/CSS/JavaScriptを使ったシンプルなWebアプリ
・タイトルは「コミックカタログ」
・コミック本はタイトル・発行番号・状態を持つ
・「未使用」「良好」「良」などの状態フィールド
・追加・削除機能と、リストのソート機能を実装…など

Clineはこのプロンプトを受け取ると、まず「計画モード」で、アプリ全体の構成案やファイル構造、使用する技術要素を、
驚くほどのスピードで提示してきました（この時点ではまだコードは生成されません）。
こちらがその設計案を承認すると、「実行モード」に切り替わり、一気にソースコードを生成→保存→動作確認テストまで自動で実施しました。

本当に私自身は1行もコードを書くことなく、指定した通りに動作するシンプルなWebアプリを手にすることができました
（実際に作成されたアプリの画面を添付します）。
想像以上の「全自動ぶり」に、正直ちょっとした驚きと違和感を覚えるほどの体験でした。

今回Clineを使ってみて特に感じたのは、生成AIによるコード生成が「試作」や「日常的な小ツールの開発」においては、
非常に強力な選択肢になり得るということです。
たとえば、ちょっとした業務効率化のためのスクリプトや、PoC（概念実証）レベルのプロトタイプを作る場面では、
従来よりも圧倒的に短時間で形にできる可能性があります。
「こんなツールがあったら便利かも」というアイデアを、AIに一気にコード化してもらい、試してみるという流れがグッと現実的になってきています。

ただ一方で、「AIが書いたコードをそのままで使う」というのは、まだリスクが大きいとも感じました。
見た目はそれっぽく動くコードが出てきても、中身をよく見ると処理の前提がずれていたり、エラー処理やセキュリティ面で不安が残るケースもあります。

特に、製品として外部に提供する商用サービスや、将来的なメンテナンス・保守を見越したシステムでは、
「AIが書いたコードが本当に正しく、安全に動作するか」を人間がチェックし、必要に応じて修正を加える工程は欠かせません。

つまり現段階では、**AIは「全自動で任せきれる相棒」というよりも、「手間を大きく減らしてくれる強力なアシスタント」**といった位置づけが現実的でしょうか。

この先、AIの性能がさらに進化し、より安全・高品質なコードが安定して生成されるようになれば、
「開発スタイルそのものが変わる日も遠くないのでは？」と感じる、そんな体験でもありました。

今回の体験を通じて、生成AIによる自動プログラミングの現実的な力と、今後の可能性を実感することができました。
AIにすべてを任せるにはまだ課題もありますが、適切に使えば開発現場の在り方を大きく変える力を持っていると感じています。

我々リーガルは、このような生成AI技術の進化にこれからもキャッチアップし続け、その成果を皆さまに分かりやすく、
実用的な形でお届けできるよう、今後も一層努力してまいります。
これからもどうぞよろしくお願いいたします。